Open jarilammi opened 6 years ago
Fixed in 7b1d6aa82aa9df25674fe623a374e24a10889439. Thank you for bug report.
Actually it's possible to implement writing CSV list for RT3/MD380. I'm pretty sure this radio has the same format of callsign database as UV380. But it's probably located at different address in memory. Need to figure out values of CALLSIGN_START, CALLSIGN_FINISH and CALLSIGN_OFFSET (see uv380.c and routine uv380_write_csv()).
Jari, can you please help me with this? I have a python script that reads the whole 16 Mbytes of internal radio memory. I can compare it with memory dump of my uv380, and find correct addresses for rt3/md380. Here is the script: https://raw.githubusercontent.com/wiki/sergev/dmrconfig/scripts/md380-read-16mb.py
You will need to install pyusb: "pip install pyusb". Then run "./md380-read-16mb.py rt3.bin" - it will dump the memory from radio into binary file rt3.bin.
BTW, there exists an easier way to get the latest list of DMR callsigns. No need for Digital Contacts Wizard. Just use:
wget https://www.radioid.net/static/users.csv
Does the radio have a separate user database or would the codeplug be flooded with those contacts? That file has 112 438 lines with 721 grepped Finnish lines now.
The radio exits the programming mode cleanly now when this error happens:
$ dmrconfig -u -t contacts.csv
--- Send GETSTATE [1]
--- Recv 02
--- Send DNLOAD [2] 91-01
--- Send GETSTATUS [6]
--- Recv 00-e8-03-00-04-00
--- Send GETSTATE [1]
--- Recv 03
--- Send ABORT
--- Send GETSTATE [1]
--- Recv 02
--- Send DNLOAD [2] a2-01
--- Send GETSTATUS [6]
--- Recv 00-32-00-00-04-00
--- Send GETSTATE [1]
--- Recv 03
--- Send ABORT
--- Send GETSTATE [1]
--- Recv 02
--- Send UPLOAD [64]
--- Recv 44-52-37-38-30-00-ff-ff-ff-ff-ff-ff-ff-ff-ff-ff-20-02-ff-33-00-40-00-48-ff-ff-ff-ff-ff-ff-ff-ff-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
--- Send GETSTATUS [6]
--- Recv 00-00-00-00-02-00
--- Send DNLOAD [5] 21-00-00-00-00
--- Send GETSTATUS [6]
--- Recv 00-32-00-00-04-00
--- Send GETSTATE [1]
--- Recv 03
--- Send ABORT
--- Send GETSTATE [1]
--- Recv 02
Connect to TYT MD-380.
TYT MD-380 does not support CSV database.
Close device.
--- Send DNLOAD [2] 91-05
--- Send GETSTATE [1]
--- Recv 02
--- Send GETSTATUS [6]
So that part is fixed.
This may not matter if you only use a couple of first fields from the CSV file anyway, but I got different formats from those two sources. The wizard responded with:
2442017,OH2K,Kauniainen,,Uusimaa,,Finland
while the direct link says:
2442017,OH2K,Kauniainen ,,,Finland,Club
Is it possible that TYT MD-380 and alike would use different data fields for contacts?
Are the CSV Contacts eventually be going to be assimilated into the codeplug contacts? If they are, they might begin at 0000ec20:
0000ec20 46 00 69 00 6e 00 6c 00 61 00 6e 00 64 00 00 00 |F.i.n.l.a.n.d...|
0000ec30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0000ec40 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0000ec50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
because Finland is the first contact in my RT-3 codeplug. But then again, there's a quite similar entry near 00005f80:
00005f50 ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 |................|
00005f60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00005f70 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff |................|
00005f80 f4 00 00 c1 46 00 69 00 6e 00 6c 00 61 00 6e 00 |....F.i.n.l.a.n.|
00005f90 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |d...............|
00005fa0 00 00 00 00 91 09 00 c1 4c 00 61 00 70 00 6c 00 |........L.a.p.l.|
00005fb0 61 00 6e 00 64 00 00 00 00 00 00 00 00 00 00 00 |a.n.d...........|
Lapland is the second contact in my codeplug. And it seems to have some kind of non-visible values. EDIT: This latter one is probably the group list.
Is it possible that TYT MD-380 and alike would use different data fields for contacts?
As I can see from uv380, the data fields are just being printed on the screen, one field per line. So the format of fields does not matter much, as long as the information is the same.
Are the CSV Contacts eventually be going to be assimilated into the codeplug contacts?
No, CSV Contacts list is a separate entity. It must be stored somewhere else. No way to fit it into a codeplug, which has only 256kbytes for RT3. Full contacts database needs 5Mbytes.
It looks like native RT3 firmware does not support CSV database. The only way to add this feature is to replace your firmware with MD380Tools version: http://md380.tools/features/
That file has 112 438 lines with 721 grepped Finnish lines now.
Jari, RT3 supports up to 1000 contacts in the codeplug. You can easily format the configuration script (device.conf) and add 721 records to the Contacts table. Then use the following command to configure the radio with new data:
dmrconfig -c your-file.conf
I found out that there is still a similar staying in the programming mode problem when the white spaces on the contact list aren't correct.
$ dmrconfig -c device.conf
Connect to TYT MD-380.
Read device: ######## done.
Last Programmed Date: 2018-11-04 00:53:26
CPS Software Version: V=0.09
Write codeplug to file 'backup.img'.
Read configuration from file 'device.conf'.
Invalid line: '359 OH2K_Kauniainen Private 2442017 -'
And then the radio stays in the programming mode without exiting it.
This problem is pretty easy to reduplicate. First generate a contact list for TYT MD-380 and then try to update that into the radio:
The radio stays in the programming mode after the error and requires a power off. Could the error handling safely add the exit from the programming mode or is the power off more beneficial if a more grave error would occur?