Bug #9499
openFTL-7011 12 channel unit is only displaying 4 channels
0%
Description
I have an FTL-7011 that is a 12 channel unit that is only displaying 4 channels after programming. I am in the Portland area and happy to deliver the unit for loan if requested. I have a programming cable. (I don't know if the problem is due to CHIRP). 73, W7MDB at . arrl.net
Files
| FTL-2011_Example.png (37.3 KB) FTL-2011_Example.png | |||
| Vertex Standard_FTL-7011_20211101.img (589 Bytes) Vertex Standard_FTL-7011_20211101.img | |||
| ftlx011_temporary_fix_#1.py (25.5 KB) ftlx011_temporary_fix_#1.py | |||
| Capture.JPG (18 KB) Capture.JPG | |||
| Yaesu Vertex FTL-2011 File Format Reverse Engineering.docx (47.7 KB) Yaesu Vertex FTL-2011 File Format Reverse Engineering.docx | Vertex FTL-x011 CE5.EXE File Format Reverse Engineering v0.1 | ||
| Vertex Standard_FTL-7011_20211231_TX_enabled.img (601 Bytes) Vertex Standard_FTL-7011_20211231_TX_enabled.img | |||
| ftlx011_notx-empty_fix_#1.py (25.2 KB) ftlx011_notx-empty_fix_#1.py | |||
| ftlx011_notx-empty_fix_#1_mitch_fix.py (25.2 KB) ftlx011_notx-empty_fix_#1_mitch_fix.py | With NOTX and Empty bits swapped in the data structure. | ||
| ftlx011_notx-empty_fix_#2.py (25.2 KB) ftlx011_notx-empty_fix_#2.py |
Updated by Jim Unroe over 2 years ago
- File FTL-2011_Example.png FTL-2011_Example.png added
- Status changed from New to Feedback
CHIRP is programmed to support 24 channels for the Vertex FTL-7011.
Did you accidentally change the Memory Range to only show 4 channels? It should be set at the top left of the spreadshett style memory editor to...
Memory Range [ 1] - [24]
Also are there empty channels and you have toggled off the [Show Empty] button?
See attached screen capture from an FTL-2011 as an example (it has the same channel range).
If neither of the above is the issue, then attach a CHIRP Radio Images (*.img) file from your FTL-7011 so that a developer has something to work with.
Jim KC9HI
Updated by Mitch Bayersdorfer over 2 years ago
Both [Show Empty] and channel range verified. After programming only channels displayed are 1,2,3 and 6. Download from radio still shows all channels so EPROM is probably storing all channels correctly. Putting known good frequency in all slots did not rectify problem. Showed all 12 channels before programming, but this radio was donated to Clackamas ARES recently, so I don't know its history.
Updated by Jim Unroe over 2 years ago
OK. I guess I misunderstood. I thought you meant there are only 4 channels showing up in CHIRP.
So after reviewing the attached "image" is was able to see that all 12 channels except for 1, 2, 3, and 6 have the "empty" bit set to 1 which tells the radio that they are empty. What seems to happen is that when a channel is erased from within CHIRP, the "empty" bit is set to 1, but later when the channel gets programmed, the "empty" bit does not get changed to 0 so the radio still, as it should, considers the channel empty.
In addition to that, the "Time out timer" feature was enabled on some channels and disabled on others with no way for the CHIRP user to enable it.
The original author is not able to look into this at this time, so I took a look to see if I could come up with at least a temporary solution for you to use until these issues can be officially sorted out. What I came up with, and have attached to this issue, is the temporary driver module called ftlx011_temporary_fix_#1.py. You will need to follow the instructions below in order to test and use this temporary fix. This temporary driver module does not permanently change your CHIRP installation in any way. So once you close CHIRP, the temporary driver module will no longer be available so you will have to load it again before you can edit your radio.
Here is how you use it...
- save the ftlx011_temporary_fix_#1.py driver module to a convenient location
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.
- open CHIRP
- click Help in the menu bar
- enable Enable Developer Functions
- click File
- click Load Module
- locate and load the driver module that was saved in step 1
The CHIRP background will now be red to indicate that an external driver module is running. Now you can program your radio using this temporary driver module to see if it works for you. Leave feedback regarding what works and what doesn't.
I also noticed that Duplex = off on all 8 of the channels that are/were not showing up in your radio. That sets them to TX disabled (RX only). I could be wrong, but I suspect that you intended to set them to Duplex = (None) which is equivalent to "simplex".
To change them all at once...
- click memory row 4 to highlight it
- shift-click memory row 12 to highlight rows 4-12
- ctrl-click memory row 6 to toggle the highlight off (leaving 4-5 and 7-12 highlighted)
- click the [Properties] button to bring up the Memories Editor
- tick the box to the left of Duplex to enable editing
- set Duplex to {blank} which is equal to (None) in the Spreadsheet Style Memory Editor
- click the [OK] button to accept the change
Also note while you are in the Memory Properties editor, the Other tab is where you will find the Busy channel lockout: setting and the newly added Time out timer: setting (which enables/disables the global Time out timer setting on a per-channel basis).
Jim KC9HI
Updated by Mitch Bayersdorfer over 2 years ago
- File Capture.JPG Capture.JPG added
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
Updated by Jim Unroe over 2 years ago
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
Updated by Mitch Bayersdorfer over 2 years ago
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
Updated by Mitch Bayersdorfer over 2 years ago
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
Updated by Mitch Bayersdorfer over 2 years ago
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
Updated by Jim Unroe over 2 years ago
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
Updated by Mitch Bayersdorfer over 2 years ago
- File Yaesu Vertex FTL-2011 File Format Reverse Engineering.docx Yaesu Vertex FTL-2011 File Format Reverse Engineering.docx added
As you requested, I have obtained a less than 388MHz Windows 95 Computer with the correct version of DOS and a serial cable so that I could reverse engineer the file format that is stored for the variables that can be accessed with the CE5.EXE Vertex software. I have also included the text from the [F1 - Help] key to help understand the variables and their interactions. I am assuming that the stored file format and the serially transmitted format are the same, but if that's not true, then we will need to figure out the mapping between the two.
This is a first draft and a few of the encodings were not obvious. Please let me know if you have any questions about what I have discovered, or need me to double check any of my work.
73,
- Mitch W7MDB
Updated by Mitch Bayersdorfer over 2 years ago
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.
Updated by Mitch Bayersdorfer over 2 years ago
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.
Updated by Jim Unroe over 2 years ago
- File Vertex Standard_FTL-7011_20211231_TX_enabled.img Vertex Standard_FTL-7011_20211231_TX_enabled.img added
Mitch Bayersdorfer wrote:
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.
That should be simple enough to fix. Below is the part of the structure that contains the notx and empty bits.
u8 notx:1, // 0 = Tx posible, 1 = Tx disabled
empty:1, // 0 = channel enabled, 1 = channed empty
tot:1, // 0 = tot disabled, 1 = tot enabled
power:1, // 0 = high, 1 = low
bclo_cw:1, // 0 = disabled, 1 = Busy Channel Lock out by carrier
bclo_tone:1, // 0 = disabled, 1 = Busy Channel Lock out by tone (set rx tone)
skip:1, // 0 = scan enabled, 1 = skip on scanning
unknownA0:1;
There were 8 channels with notx set to 1 (Tx disabled). I used CHIRP to set the notx bit of these 8 channels to 0. Did that make a difference?
Jim KC9HI
Updated by Mitch Bayersdorfer over 2 years ago
I have verified that clearing the "empty" bit fixes the problem. Thanks!
- Mitch
Updated by Mitch Bayersdorfer over 2 years ago
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.
Updated by Mitch Bayersdorfer over 2 years ago
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
Updated by Jim Unroe over 2 years ago
Looking closer at the code, it appears that when the [Delete] key is pressed, the empty bit is set to True as it should be. Unfortunately when data is eventually entered into an "empty" memory row, the empty bit is not reset and the radio will continue to consider the memory empty.
It seems that there is a similar issue for the notx bit. If Duplex is set to "off" the notx bit is set to True and the radio will not TX. But if Duplex is then set to something else ("(none)", "+", "-" or "split"), nothing changes the notx bit back to False and the radio will still not TX.
I believe that the changes that I made in this test driver module will fix this. Try it out and let me know if it corrects these issues or not.
Jim KC9HI
Updated by Mitch Bayersdorfer over 2 years ago
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
Updated by Mitch Bayersdorfer over 2 years ago
...And the CHIRP user interface does not reflect that NOTX is still high.
- Mitch
Updated by Jim Unroe over 2 years ago
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
Updated by Mitch Bayersdorfer over 2 years ago
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.
Updated by Mitch Bayersdorfer over 2 years ago
I have not done any real testing, but with respect to the Empty Bit, this version seems to be working better.
Have a Happy New Year!
73,
- Mitch
Updated by Mitch Bayersdorfer over 2 years ago
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.
Updated by Jim Unroe over 2 years ago
For the fun of it I swapped the empty and notx bits in the structure. Any better?
Jim KC9HI
Updated by Mitch Bayersdorfer over 2 years ago
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
Updated by Jim Unroe over 2 years ago
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
Updated by Mitch Bayersdorfer over 2 years ago
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