[chirp_devel] New model: Polmar DB50M, should be Anytone AT-5888UV clone but...
Hi all!
Happy Newyear!
Hi, I purchased a Polmar DB-50M, which is a clone of the Anytone AT-5888UV, with minor differences. The most important difference is that it supports 7 character channel names.
I read the model name from the debug file: User selected AnyTone 5888UV on port COM9 Clone thread started 000: 49 44 42 2d 35 30 4d 00 IDB-50M. 008: 00 56 31 30 30 e4 00 06 .V100...
I also read the Intek 2040 issue and tried to create a polmar-db50m.py file based on the intek.py file (changed the vendor, model and classname), but loading the module seems to time-out when reading the radio:
@directory.register class PolmarDB50Madio(chirp_common.CloneModeRadio, chirp_common.ExperimentalRadio): """Polmar DB-50M""" VENDOR = "Polmar" MODEL = "DB-50M"
Is there a FAQ on how to create a *.py file yourself? I don;t mind tinkering a py file and I'm not scared of programming.
(copy from http://chirp.danplanet.com/issues/1343, files are also posted there)
Tom Hayward suggested I capture the programming data to compare to the Anytone data, is there a tool I can use which works?
Okay, sorry, I forgot this was started here since the discussion ended up all in the issue.
I also read the Intek 2040 issue and tried to create a polmar-db50m.py file based on the intek.py file (changed the vendor, model and classname), but loading the module seems to time-out when reading the radio:
If you create a new .py file there and change the VENDOR and MODEL strings as you have, then CHIRP will register it and make it available for selection in the UI. If you see the right vendor/model in the drop-downs during the download part, you can be sure that you're running the code in that file.
Okay, I have compared the two files and they start of exactly the same with the sending PROGRAM and receiving PROGRAMSQ Ox06. Then the command sent is the same every time (0x52 00 20 10, at least for the first couple of times I compred them), but the answer is different. Not a surprise, since it starts with a query for the model number. However, the length of the answer is the same (26). And later in the log, when querying the channels, the command seems to be the same for both models and theanswer is the same length.
Probably the best thing to do to get bootstrapped is start dropping print statements into your module to help you understand where exactly it's getting stuck, and confirm what you're getting back from the radio in each step. Looking at the other code will help, but this should be most of what you want:
print util.hexprint(foo)
where "foo" is some string variable of data you just read from the radio.
I think you're doing your development in Windows, right? Did you get a full development environment setup or are you trying to shove your .py into the frozen zip each time you make a change?
--Dan
On 4-1-2014 16:57, Dan Smith wrote:
Okay, sorry, I forgot this was started here since the discussion ended up all in the issue.
I also read the Intek 2040 issue and tried to create a polmar-db50m.py file based on the intek.py file (changed the vendor, model and classname), but loading the module seems to time-out when reading the radio:
If you create a new .py file there and change the VENDOR and MODEL strings as you have, then CHIRP will register it and make it available for selection in the UI. If you see the right vendor/model in the drop-downs during the download part, you can be sure that you're running the code in that file.
This works. I see it enabled in the debug.log also: Registered Polmar_DB-50M = PolmarDB50MRadio
Okay, I have compared the two files and they start of exactly the same with the sending PROGRAM and receiving PROGRAMSQ Ox06. Then the command sent is the same every time (0x52 00 20 10, at least for the first couple of times I compred them), but the answer is different. Not a surprise, since it starts with a query for the model number. However, the length of the answer is the same (26). And later in the log, when querying the channels, the command seems to be the same for both models and theanswer is the same length.
Probably the best thing to do to get bootstrapped is start dropping print statements into your module to help you understand where exactly it's getting stuck, and confirm what you're getting back from the radio in each step. Looking at the other code will help, but this should be most of what you want:
print util.hexprint(foo)
where "foo" is some string variable of data you just read from the radio.
I think you're doing your development in Windows, right? Did you get a full development environment setup or are you trying to shove your .py into the frozen zip each time you make a change?
I am just editing the .py file at the moment. I'm not a developer, but seeing how easy it was for an Intek HR-2040 owner to edit the .py file I just dived in. Attached is the .py file I eneded up with, but after only changing any accurrence of Intek to Polmar and HR-2040 to DB-50M, I do not even get the experimental warning. And if I try to read the DB-50M as an Intek HR-2040 I do get that (but also get an unsupported model just after that).
This baffles me... I see the class PolmarDB50MRadio getting registered in the debug logfile, can pick the model for a read and then nothing. I expected at least the experimental warning and an error, but get some cryptic log statements instead:
Traceback (most recent call last): File "chirpui\mainapp.pyo", line 1357, in mh File "chirpui\mainapp.pyo", line 615, in do_download File "chirpui\mainapp.pyo", line 573, in _confirm_experimental File "chirpui\common.pyo", line 348, in show_warning File "chirpui\common.pyo", line 308, in _add_text TypeError: GtkTextBuffer.set_text() argument 1 must be string or read-only buffer, not None
I compared the Portmon logs from a Anytone AT-5888UV to my DB-50M and the commands are the same and the only thing different at the start is the model name, but it is in the same format...
This works. I see it enabled in the debug.log also: Registered Polmar_DB-50M = PolmarDB50MRadio
Right, okay, so you should be running the code you think you are.
I am just editing the .py file at the moment. I'm not a developer, but seeing how easy it was for an Intek HR-2040 owner to edit the .py file I just dived in. Attached is the .py file I eneded up with, but after only changing any accurrence of Intek to Polmar and HR-2040 to DB-50M, I do not even get the experimental warning. And if I try to read the DB-50M as an Intek HR-2040 I do get that (but also get an unsupported model just after that).
But from what source? The bit of code you pasted into the issue looks like it's really old (i.e. not what is in the upstream repository). If you're using the .exe windows build, changing what is in that frozen environment may give you issues and not behave exactly the way you expect. Are you using chirp's module loader or modifying the library zip?
This baffles me... I see the class PolmarDB50MRadio getting registered in the debug logfile, can pick the model for a read and then nothing. I expected at least the experimental warning and an error, but get some cryptic log statements instead:
Traceback (most recent call last): File "chirpui\mainapp.pyo", line 1357, in mh File "chirpui\mainapp.pyo", line 615, in do_download File "chirpui\mainapp.pyo", line 573, in _confirm_experimental File "chirpui\common.pyo", line 348, in show_warning File "chirpui\common.pyo", line 308, in _add_text TypeError: GtkTextBuffer.set_text() argument 1 must be string or read-only buffer, not None
I expect this is because you're modifying a frozen environment. This is likely stopping you before it ever tries to talk to the radio. Instead of putting your new .py file into the library, keep it out and use File->Load Module inside of chirp. This needs to be done every time you start it for testing.
I expect that all that needs to happen is for us to add the identifier to the existing list. So, if you would, try the following:
1. Download the latest daily build 2. Enable developer functions in the Help menu 3. Go to File->Load Module and select the attached file
Then try to download it by choosing the Anytone model (for now) and send me the resulting debug log on the list here.
Thanks!
--Dan
On 4-1-2014 17:17, Dan Smith wrote:
This works. I see it enabled in the debug.log also: Registered Polmar_DB-50M = PolmarDB50MRadio
Right, okay, so you should be running the code you think you are.
That's wahat I was thinking. ;)
I am just editing the .py file at the moment. I'm not a developer, but seeing how easy it was for an Intek HR-2040 owner to edit the .py file I just dived in. Attached is the .py file I eneded up with, but after only changing any accurrence of Intek to Polmar and HR-2040 to DB-50M, I do not even get the experimental warning. And if I try to read the DB-50M as an Intek HR-2040 I do get that (but also get an unsupported model just after that). But from what source? The bit of code you pasted into the issue looks like it's really old (i.e. not what is in the upstream repository). If you're using the .exe windows build, changing what is in that frozen environment may give you issues and not behave exactly the way you expect. Are you using chirp's module loader or modifying the library zip?
I found an issue about an Intek HR-2040 on the site: http://chirp.danplanet.com/issues/1125
Here it mentions editing a py file, which sounded really easy. :) So I picked the intek.py file and edited that. That file is about 4 months old, so may indeed be outdated.
This baffles me... I see the class PolmarDB50MRadio getting registered in the debug logfile, can pick the model for a read and then nothing. I expected at least the experimental warning and an error, but get some cryptic log statements instead:
Traceback (most recent call last): File "chirpui\mainapp.pyo", line 1357, in mh File "chirpui\mainapp.pyo", line 615, in do_download File "chirpui\mainapp.pyo", line 573, in _confirm_experimental File "chirpui\common.pyo", line 348, in show_warning File "chirpui\common.pyo", line 308, in _add_text TypeError: GtkTextBuffer.set_text() argument 1 must be string or read-only buffer, not None
I expect this is because you're modifying a frozen environment. This is likely stopping you before it ever tries to talk to the radio. Instead of putting your new .py file into the library, keep it out and use File->Load Module inside of chirp. This needs to be done every time you start it for testing.
That is how I load the Polmar py file. I change nothing in the Chirp environment itself.
I expect that all that needs to happen is for us to add the identifier to the existing list. So, if you would, try the following:
- Download the latest daily build
- Enable developer functions in the Help menu
- Go to File->Load Module and select the attached file
Then try to download it by choosing the Anytone model (for now) and send me the resulting debug log on the list here.
That one is easy and what I tried in the first place to get the correct model string. :)
debug.log attached. And using Portmon I already verified that the Polmar DB-50M indeed responds to the model query with "DB-50M". Portmon logs are also attached, they are created by using the official Polmar DB-50M software (which works fine, but does not have a CSV import function).
That is how I load the Polmar py file. I change nothing in the Chirp environment itself.
Okay, good.
That one is easy and what I tried in the first place to get the correct model string. :)
debug.log attached.
I don't see that you loaded the file I sent in your debug.log.
--Dan
On 4-1-2014 17:34, Dan Smith wrote:
That is how I load the Polmar py file. I change nothing in the Chirp environment itself.
Okay, good.
That one is easy and what I tried in the first place to get the correct model string. :)
debug.log attached.
I don't see that you loaded the file I sent in your debug.log.
Oops... must have missed that... Using that file it reads the radio just fine. :)
Logfile attached.
I also edited one channel (actually cut/paste into different channel number) and wrote that back to the radio. Logfile also attached.
I then used the official software to read the radio. Al channels seem to be intact and only minor "damage" to the settings, since those are not supported. I can live with that for now, but I'm willing to help to figure those out too if you want that.
Oops... must have missed that... Using that file it reads the radio just fine. :)
Cool. Can you try this updated version just to make sure? Also, please save out a .img of the radio and send it to me so I can put it into the tests.
If this works, I'll commit and push for tomorrow's daily build.
I then used the official software to read the radio. Al channels seem to be intact and only minor "damage" to the settings, since those are not supported. I can live with that for now, but I'm willing to help to figure those out too if you want that.
Hmm, there should be no "settings damage" unless you mean some setting on the memory you touched. The rest of the radio's image should be unchanged. Do you just mean that some bit got flipped for the channel you edited? That's expected.
--Dan
On 4-1-2014 18:00, Dan Smith wrote:
Oops... must have missed that... Using that file it reads the radio just fine. :)
Cool. Can you try this updated version just to make sure?
Debug.log attached.
Also, please save out a .img of the radio and send it to me so I can put it into the tests.
If you can tell me how to do that, no problem. I see no "save image" anywhere on the menu ((although it's partially in dutch... which is my OS preffered language).
If this works, I'll commit and push for tomorrow's daily build.
I then used the official software to read the radio. Al channels seem to be intact and only minor "damage" to the settings, since those are not supported. I can live with that for now, but I'm willing to help to figure those out too if you want that.
Hmm, there should be no "settings damage" unless you mean some setting on the memory you touched. The rest of the radio's image should be unchanged. Do you just mean that some bit got flipped for the channel you edited? That's expected.
The Emergency Information got reset to default (no big deal) and the HL/HR part of the two Hyperchannel configs also got reset. Don't know if the radio actually uses those though and I can also live with that.
I also can't edit most configuration settings, but they didn't get touched after reading the radio and writing the config back. So happy camper so far! :)
If you can tell me how to do that, no problem. I see no "save image" anywhere on the menu ((although it's partially in dutch... which is my OS preffered language).
File -> Save.
I also can't edit most configuration settings, but they didn't get touched after reading the radio and writing the config back. So happy camper so far! :)
Right, that driver has very little decoding of that information. Feel free to do that work :)
--Dan
On 4-1-2014 18:19, Dan Smith wrote:
If you can tell me how to do that, no problem. I see no "save image" anywhere on the menu ((although it's partially in dutch... which is my OS preffered language).
File -> Save.
LOL! You tend to overlook things that simple... Attached!
I also can't edit most configuration settings, but they didn't get touched after reading the radio and writing the config back. So happy camper so far! :)
Right, that driver has very little decoding of that information. Feel free to do that work :)
What would be the best way of doing that? I don't mind saving binary files and changing one configuration setting at a time to figure out what is what. Since the data is probably the same for all 5888UV clones, I will gladly do some of that work and help others at the same time. ;)
Can this be done by poking around in the IMG file Chirp saves? If I as an example tell you the setting for the Beep is at offset 0xABCD and 0x00 is Off and 0x01 is On, is that helpfull? Or do I need to capture the serial data and deduct something from that?
On 4-1-2014 18:00, Dan Smith wrote:
Hmm, there should be no "settings damage" unless you mean some setting on the memory you touched. The rest of the radio's image should be unchanged. Do you just mean that some bit got flipped for the channel you edited? That's expected.
Just did another check and there must have been something configured like I didn;t expect, because everything is now like it was uploaded to the radio by the official software. I wrote the default config for me to the radio with the official software, then read and wrote from Chirp, read again with the official software and everything was exactly like it was before.
PS. must have posted the previous message (containing the debug.log) from my other mailaddress and it is waiting for approval... sorry for that.
participants (3)
-
Dan Smith -
Robert Elsinga -
Robert Elsinga (PC5E)