CHIRP

You can actually reproduce the issue yourself if you open the attached .img file and try to edit it in the way described.

M B wrote in #note-4:

You can actually reproduce the issue yourself if you open the attached .img file and try to edit it in the way described.

Perfect. If I can solve it quickly, I will submit it tonight. If I can't, we can work on it tomorrow. Thanks.

M B wrote in #note-7:

Two last things:
The programmable frequency range with the new driver is now 400 to 519 mhz. But every value above 480 channel does not show up in the radio. Did you set it to 400-519mhz instead of 400-480mhz on purpose?

This is the why it has always been. Since the channels were restricted to 462 MHz (FRS) and 446 MHz (PMR), the issue was never discovered.

Second, the value for empty slots differs from the stock one.
See img and files attatched, channels 17 to 20 have been programmed empty with retevis software. Channel 90 to 99 have been programmed with chirp and then deleted with chirp and reuploaded. They still show up in the radio and when selected the radio flashes green and red.

I guess that has something to do with that:
# if empty memory
if mem.empty:
_mem.set_raw("\xFF" * 8 + "\x00" * 5 + "\xFF" * 3)
return
in lines 538 - 541

I changed it to
# if empty memory
if mem.empty:
_mem.set_raw("\xFF" * 8 + "\xFF" * 5 + "\xFF" * 3)
return
and now it works.

I didn't think that this looked right last night and almost changed it. Then I thought that is has been that way for a year with no complaints, maybe I better leave it along. But again, since the 22 (FRS) and 16 (PMR) channels were fixed and could not be (easily) deleted, the bug was never experienced.

I am working on getting the changes committed. Thank you for the testing. I haven't located my RB15/RB615 radios yet.

Nice! Thank you.
I loaded the new module once more from your githup repo and tested it and it seems to work. It just needs to get merged now.

M B wrote in #note-10:

Nice! Thank you.
I loaded the new module once more from your githup repo and tested it and it seems to work. It just needs to get merged now.

Thank you for the great testing. The clear explanations and photos were very helpful. I didn't attach a "_4.py" since it would have been basically the same as the "_3.py" that you attached.

I did finally find my RB15 and RB615 radios and their programming cable. That allowed me to fully understand what you were describing about frequencies above 480 MHz.

Jim KC9HI

I can up and download the channels from the memory, but the radio doesnt show them.

M B wrote in #note-13:

I can up and download the channels from the memory, but the radio doesnt show them.

I see what the problem is. I'm on it.

While you are at it. Can you set the default value for "encode:1, // Encode" to "0" as well? It doesnt make any difference whether encryption is set or not since the radio doesnt support it.
But it may be confusing for other users to have it activated by default on every newly setup channel.

M B wrote in #note-15:

While you are at it. Can you set the default value for "encode:1, // Encode" to "0" as well? It doesnt make any difference whether encryption is set or not since the radio doesnt support it.
But it may be confusing for other users to have it activated by default on every newly setup channel.

Nevermind. Doesnt work that easy. When changing the value to 0 it gives a syntax error when reading memory.

I can create new channels now.

But the "unknown1" is still 1 in chirp vs 0 in official retevis software. I have no clue what it does but wouldnt it be best to just go along with the official software just to avoid any possible bugs?

And just for my understanding: To set unkonwn1 and encode both to 0 by default I would just add

    _mem.unknown1 = False
    _mem.encode = False

In the " set_memory() " section?
Does Order matter here?

Yes it does as in one would just add the values not as in order does matter.

M B wrote in #note-19:

And just for my understanding: To set unkonwn1 and encode both to 0 by default I would just add

    _mem.unknown1 = False
    _mem.encode = False

In the " set_memory() " section?
Does Order matter here?

Well it would depend on what you are trying to do.

False = 0 and True = 1 so you could also use _mem.encode = 0

What are you trying to accomplish? When I create a new channel, Encode defaults to Disabled.

And if you force Encode = 0 in set_memory(), then you basically disabled the Encode setting. Setting Encode to Enabled would never work.

I can do this with mem.isused because there is no setting exposed to the user. It just needs to be set to 0 for every programmed channel. But if someone wanted to, there could be a setting added so you could program 99 channels and turn them off individually without deleting them and then be able to turn them back on again later. Kind of like skipping a channel when scanning.

You are right. Encode is off by default. I clould swear the default setting for encode with the initial driver was activated. But maybe it was just something odd on my side.
Ah ok. Now I understand what that section does. Thanks.

So what about the unkonw1?
Set the "_mem.unknown1 = False" to be parallel with official software or leave it as it is?

I tested it, it works with "_mem.unknown1 = False" and produces then the exact same memory blocks as the retevis software.

What are you trying to do? There is probably a better way to do it. Which factory software are you using?

You can download the software here if you want. Link is valid for 7 days.
This software is locked to pmr/frs frequencies.

https://nextcloud.mxbchr.duckdns.org/index.php/s/WE8LfXiwPAnmy5W

Copy channels, create from scratch, 400 to 479 mhz works now. Radio shows all those channels an tx/rx on them.
Memory blocks are exactly the same as when programmed with tool mentioned above.
Anything else you want me to check?

M B wrote in #note-27:

You can download the software here if you want. Link is valid for 7 days.
This software is locked to pmr/frs frequencies.

https://nextcloud.mxbchr.duckdns.org/index.php/s/WE8LfXiwPAnmy5W

Got it. Thanks

M B wrote in #note-28:

Copy channels, create from scratch, 400 to 479 mhz works now. Radio shows all those channels an tx/rx on them.
Memory blocks are exactly the same as when programmed with tool mentioned above.
Anything else you want me to check?

I think we have it. Unless you disagree, I will commit what we have now. If something else is discovered, we can open a new ticket to cover it separately.

The latest changes have been force-pushed. All tests passed. Just need to patiently wait for it to be merged.

See: https://chirp.danplanet.com/issues/10790