CHIRP

Mitch Bayersdorfer wrote:

Jim -

Thanks so much for your fast reply. Are you sure you sent the right file? What I see is html code, not python, and when it is loaded, I get the attached error message.

73,

• Mitch

Yes. I attached the correct file. You didn't heed my note above (repeated below). ;-)

Note: Do not right-click the link to download. Left-click the link and then click the download link at the top of the page that loads.

Jim KC9HI

Sorry about that... I got confused by the two different download links on that page and got lost when I clicked the top one. I should have looked more thoroughly.

73,

• Mitch

Jim -

Thanks so much for all your fast help. I was able to clear the empty bits with the editor, just need to do some more testing to see if everything else is ok. Really appreciate all that you do for the community with this app. In this case, you are keeping about a dozen radios out of the landfill.

73,

• Mitch W7MDB

Jim -

The notx field is 0x0 and that is having each channel properly display, and receive its frequency. So that is fixed now.

Independent of whether the tot field is 0x0 or 0x1 the radio insists on being receive only on all channels now. Downloading the programmed values verifies the EPROM has stored what it has been told to. I cannot find a displayed field that corresponds with turning transmit on. I have set the other settings in the fields the same as a known good radio. All the other fields in that bit vector are 0x0.

I have turned off Time Out Timer in the Settings Tab, but that seems to make no difference.

Update: now every time I program the radio now, it displays E2, indicating that it has no programming. So I believe that the EEPROM in this radio might be toast now (or something else is bad). I have a bunch of FTL-2011s, so if you want to continue this ticket, we can try whatever you want with those radios.

I might try and see what happens with an ancient DOS laptop and the ancient software and a breadboarded serial cable if you need me to, otherwise, this might now be a parts radio.

Thanks for all your help.

73,

• Mitch

Mitch Bayersdorfer wrote:

Jim -

The notx field is 0x0 and that is having each channel properly display, and receive its frequency. So that is fixed now.

All that the "notx" bit affects is if the channel will tx or not. It is the "empty" bit that determines if the channel is available or not.

Independent of whether the tot field is 0x0 or 0x1 the radio insists on being receive only on all channels now.

The "tot" bit has nothing to do with if the radio will receive or not. It only affects if the global "Time out time" setting is effective on this channel or not.

Downloading the programmed values verifies the EPROM has stored what it has been told to.

It would be nice for me to be able to see this as well.

I cannot find a displayed field that corresponds with turning transmit on.

I explained this above. Setting the Duplex field to "off" disables TX. Setting Duplex to anything other than "off" will enable TX.

I have set the other settings in the fields the same as a known good radio. All the other fields in that bit vector are 0x0.

I have turned off Time Out Timer in the Settings Tab, but that seems to make no difference.

Again, as I explained above, this is controlled by the "Time out timer" setting accessed from the Memory Editor, not the Settings tab.

Update: now every time I program the radio now, it displays E2, indicating that it has no programming. So I believe that the EEPROM in this radio might be toast now (or something else is bad). I have a bunch of FTL-2011s, so if you want to continue this ticket, we can try whatever you want with those radios.

What happens when you upload the original "image" back into the radio? It should put it back to the way the radio was when you started.

I might try and see what happens with an ancient DOS laptop and the ancient software and a breadboarded serial cable if you need me to, otherwise, this might now be a parts radio.

It would be useful to look at channels that have been programmed the way you want them using the OEM software. Especially if you could provide an examples of empty channels, tx disabled channels, tot enabled/disabled, etc. Just program with the OEM software and then read them into CHIRP. For the "empty" channel, program one with the OEM software and then change it to "empty".

Jim KC9HI

For one of my working Vertex FTL-2011 radios, I have verified that the file produced by CE5.EXE and produced by the developer module in Chirp are the same up for all of the rows that seem to matter, with the exception of byte OF (which is unknown), and I don't know if it matters. In CE5, the byte is 96, and in Chirp, byte OF is FF. I will check the radios which have the "missing channels" to see if I can see a difference.

I think I have found the issue with one of my bad radios. If Y is the channel row number, then bit 6 (if bit 0 is the low order digit) of byte Y0 is "Transmit Inhibit" The Chirp software does not allow this bit to be edited/overwritten, so if the radio has any channels with "Transmit Inhibit" already enabled, then those channels will continue to be inhibited.

I have verified that clearing the "empty" bit fixes the problem. Thanks!

• Mitch

To be clear, if the "empty" bit is set, the CE5 software displays as Tx Inh in the Tx Frequency column, so perhaps your data structure should be updated to indicate. What you have labelled as "Not X" is what happens when the channel is "hidden", so perhaps your data structure documentation is backwards.

Actually, I think the CE5.exe software has the interface wrong, and your documentation is correct, but in any event, it is the "empty" bit that needs to be cleared when setting a new CHIRP frequency.

Hopefully, my reverse engineering might help you with some of the other undocumented bits if you need to control them.

Best wishes!

• Mitch

I quit chirp and loaded your new version, but unfortunately this did not fix it. From what I can see, you are now clearing bit 6, which is transmit inhibit (which is incidentally something you might want to expose in the interface for those frequencies that are out of the ham band), but also you need to clear bit 7, which the CE5 software labels as "Hidden" (you call it NOTX).

I created a file where every other station was "Hidden" using the CE5 software, uploaded it, and then downloaded it using CHIRP. I then showed empty stations, updated all of the "empty" stations. Saving that file, I still have hex 80 in all of the byte 0 stations that were previously "hidden", and uploading that file, I those stations are skipped when tuning.

73,

• Mitch

...And the CHIRP user interface does not reflect that NOTX is still high.

• Mitch

Mitch Bayersdorfer wrote:

I quit chirp and loaded your new version, but unfortunately this did not fix it. From what I can see, you are now clearing bit 6, which is transmit inhibit (which is incidentally something you might want to expose in the interface for those frequencies that are out of the ham band), but also you need to clear bit 7, which the CE5 software labels as "Hidden" (you call it NOTX).

I created a file where every other station was "Hidden" using the CE5 software, uploaded it, and then downloaded it using CHIRP. I then showed empty stations, updated all of the "empty" stations. Saving that file, I still have hex 80 in all of the byte 0 stations that were previously "hidden", and uploading that file, I those stations are skipped when tuning.

73,

• Mitch

Not according to the driver structure. Bit 6 is "empty" and bit 7 is "notx".

Without a physical radio in my possession or test images like you created, there is not much I can do. I'm not the author of this driver and I don't own any Yaesu radios so I my experience is limited (if not non-existent).

Jim KC9HI

I double checked, and based on how the radio is performing, I believe was correct that your program has NOTX and Empty swapped in the data structure.

What is currently labeled NOTX (bit 7) should be the bit that is
0 = channel enabled, 1 = channel empty

and what is currently labelled "empty" (bit 6) should be the bit that is 0 = Tx possible, 1 = Tx disabled.

I'm happy to go through all the white box programming use cases that the FTL Python program presents for both the Tx Inh bit and the Empty bit. I'm also happy to send a FTL-x011 radio to anyone in your team that you like to verify that I have the data structure correct. I am in the Portland area, so if it is convenient, I can bring a radio to Dan for him to verify.

Yes, that seems to be the right fix... It properly enables all of the channels that are edited while "empty."

I independently did this fix a few hours ago (see above), and a few quick tests that I already did show that it seems to be working. I need to go through the program logic to make sure that the use cases for editing, turning on and off duplex, etc seem to be working as well.

I will let you know what my testing uncovers in the next few days, but intuitively, that seems to be the right fix for me.

Thanks for all your help.

73,

• Mitch

Mitch Bayersdorfer wrote:

Yes, that seems to be the right fix... It properly enables all of the channels that are edited while "empty."

I independently did this fix a few hours ago (see above), and a few quick tests that I already did show that it seems to be working. I need to go through the program logic to make sure that the use cases for editing, turning on and off duplex, etc seem to be working as well.

I will let you know what my testing uncovers in the next few days, but intuitively, that seems to be the right fix for me.

Thanks for all your help.

73,

• Mitch

Yeah... I must have been working on my changes when you attached yours and missed it.

Anyway, I just sent an email to Pavel, the driver's original author, to see if he would assist with these changes.

Jim KC9HI

Thanks - please let Pavel know that I have tested your changes on my end and that they seem correct. Please also let Pavel know about my reverse engineering in case he wants to use it for future improvements.

73,

• Mitch