- Developers - lists.chirpmyradio.com

[chirp_devel] Issues in bitwise.py
by Daniele Forsi 07 Feb '24

07 Feb '24

Hello, the driver kyd_IP620.py has a channel memory structure of 16 bytes but printing it shows a length of 15 bytes. I get this output: struct { memory: struct { rx_freq: 4:[(0)] tx_freq: 4:[(0)] rx_tone: 0x0000 tx_tone: 0x0000 unknown_1: 0x00 (....0000b) busy_loc: 0x00 (......00b) n_a: 0x00 (......00b) unknown_2: 0x00 (.......0b) scan_add: 0x00 (.......0b) w_n: 0x00 (.......0b) lout: 0x00 (.......0b) n_a_: 0x00 (.......0b) power: 0x00 (......00b) unknown_3: 0x00 unknown_4: 0x00 } memory (15 bytes at 0x0000) } (anonymous) (15 bytes at 0x0000) using the following script === from chirp import bitwise defn =""" struct { // Channel memory structure lbcd rx_freq[4]; // RX frequency lbcd tx_freq[4]; // TX frequency ul16 rx_tone; // RX tone ul16 tx_tone; // TX tone u8 unknown_1:4, // n-a busy_loc:2, // NO-00, Crrier wave-01, SM-10 n_a:2; // n-a u8 unknown_2:1, // n-a scan_add:1, // Scan add n_a:1, // n-a w_n:1, // Narrow-0 Wide-1 lout:1, // LOCKOUT OFF-0 ON-1 n_a_:1, // n-a power:2; // Power low-00 middle-01 high-10 u8 unknown_3; // n-a u8 unknown_4; // n-a } memory[1]; """ data = bytearray(b"\x00" * 16) tree = bitwise.parse(defn, data) print(tree) === I do not own such a radio but the same issue could be present in other drivers. I think that the reason is that n_a is used twice, so I reduced the definition to this defn =""" struct { u8 n_a:2; u8 n_a:1; } memory[1]; """ but this throws a RecursionError exception at .../chirp/bitwise.py", line 878, in do_bitfield LOG.warn("WARNING: %i trailing bits unaccounted for in %s" % I would submit a pull request but I don't know how to handle the following issues in bitwise.py: * line 878 doesn't correctly handle the name that it needs to print, but I don't know how to fix it * the __repr__ of class structDataElement and possibly 4 other lines of code shouldn't use the integer division self.size() // 8 or the size should be automatically padded to the next multiple of 8 with a dummy member? * should there be a warning for reused names of struct members or an exception? thanks -- 73 de IU5HKX Daniele

2 2

[chirp_devel] Memory area modification
by Tommy 12 Jan '24

12 Jan '24

Hello and Happy new year ! I am part of a project which aims to create open source firmware to improve the features of the Radtel RT890 Radio and its clones (Ruyage UV58Plus / Iradio UV 5118 plus). We use a custom version of the iradio_uv_5118plus.py driver which works, we modified the frequency limits, the modulations, added the scanlists... In an attempt to remain compatible with the manufacturer's firmware we stored most of new settings outside of the original settings memory area, I tried integrating that area into the chirp image and it didn't go well... The new memory area (0x3D5000) is located after the original settings area (0x3C1000). My intention was to increase the value of END_ADDR and _memsize to download memory from the start of the original area to the end of the new area, then add an entry in _ranges to write the new settings. During my tests, I obtain an image which is the desired size but its content cycle the original area (basically if I double the size, I have twice the original information concatenated). There are no errors in debug log and the addresses printed by do_download and _read_block seem good. I tried just changing the READ_OFFSET starting address (0x7960 instead of 0x7820) leaving the size as is and I still get the original data. I don't have the impression that it is our firmware that exclusively returns this address range because we have a tool that dumps the entire SPI memory (4MB) and uses the same UART commands. This behavior is the same on a radio with the stock firmware, to reproduce you just need to change the value of READ_OFFSET, by putting 0x7960 for example and you will still obtain the data of the original area. Do you think I forgot to do something? Many Thanks !

2 2

[chirp_devel] Yaesu FTM-500DR
by dropkick23＠gmail.com 29 Dec '23

29 Dec '23

I would like to request a SDCard BACKUP.dat file for FTM-500. ADMS software requires a read from the radio or BACKUP.dat file to function. I don't have a radio. Thinking of starting a project to add FTM-500 to chirp and need an image to evaluate. Thanks, Fred dropkick23(a)gmail.com

3 7

[chirp_devel] Python 3.11
by dropkick23＠gmail.com 13 Dec '23

13 Dec '23

Is 3.11 supported now? I see wxPython 4.2.1 was released with support for 3.11. Fred

2 2

[chirp_devel] Test code for a suspected Baofeng clone
by wcurlew＠juno.com 22 Nov '23

22 Nov '23

I have a Golden Spring GS-UVF9 handheld that works a lot like a baofeng. It is 2m, 1.25m capable but has only a black and white display. I've tried a bunch of differnt makes and models and can't get it to respond to a programming "magic word", even though the display does react. A serial monitor shows no response to read. Is there a utility in Chirp that will cycle though a known list of program/read commands? The old programming software for this radio is not available, and was not stored on the "wayback" machine. TH700? Thanks, Bill

1 0

Re: [chirp_devel] [CHIRP - Feature #10929] (Closed) TYT UV8000D Add Menu Number to Settings and improve descriptions
by Rick (AA0RD) DeWitt 09 Nov '23

09 Nov '23

Howdjadothat? I never got around to a pull request, but thanks. On 11/7/2023 3:30 PM, Dan Smith wrote: > Issue #10929 <https://chirp.danplanet.com/issues/10929#change-39849> > has been updated by Dan Smith. > ------------------------------------------------------------------------ > > * *Status* changed from /New/ to /Closed/ > * *% Done* changed from /0/ to /100/ > > Applied in changeset github|6b083e22e4af9ce577564e27051b0226c928eee2 > <https://chirp.danplanet.com/projects/chirp/repository/github/revisions/6b08…>. > > ------------------------------------------------------------------------ > > > Feature #10929: TYT UV8000D Add Menu Number to Settings and improve > descriptions <https://chirp.danplanet.com/issues/10929#change-39849> > closed > > * *Author: *Rick DeWitt > * *Status: *Closed > * *Priority: *Normal > * *Assignee: *Rick DeWitt > * *Category: *UI Features > * *Target version: *chirp-py3 > * *Start date: *2023-11-05 > * *Due date: *2023-12-25 > * *Chirp Version: *next > * *Model affected: *TYT UV-8000D > * *I read the instructions above: *Yes > > User requested the addition of the radio menu sequence number to the > Settings parameters. > Good idea! > > ------------------------------------------------------------------------ > > You have received this notification because you have either subscribed > to it, or are involved in it. > To change your notification preferences, please click here: > http://chirp.danplanet.com/my/account >

4 6

[chirp_devel] Can't get makesupported to work
by wcurlew＠juno.com 02 Nov '23

02 Nov '23

Know it must be something simple, but can't get a clean run of makesupported. here is output, can anybody suggest why this is failing? Both FT-450 and FT450D classes are in the FT-450D.py module Thanks, Bill Microsoft Windows [Version 10.0.19045.3570] (c) Microsoft Corporation. All rights reserved. C:\Users\wcurlew>cd chirp C:\Users\wcurlew\Chirp>tox -e makesupported .pkg: _optional_hooks> python C:\Users\wcurlew\AppData\Local\Programs\Python\Python310\lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__ .pkg: get_requires_for_build_sdist> python C:\Users\wcurlew\AppData\Local\Programs\Python\Python310\lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__ .pkg: get_requires_for_build_wheel> python C:\Users\wcurlew\AppData\Local\Programs\Python\Python310\lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__ .pkg: prepare_metadata_for_build_wheel> python C:\Users\wcurlew\AppData\Local\Programs\Python\Python310\lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__ .pkg: build_sdist> python C:\Users\wcurlew\AppData\Local\Programs\Python\Python310\lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__ makesupported: install_package> python -I -m pip install --force-reinstall --no-deps C:\Users\wcurlew\Chirp\.tox\.tmp\package\107\chirp-0.tar.gz makesupported: commands[0]> python chirp/share/make_supported.py model_support.html makesupported: commands[1]> python tools/py3_driver_progress.py -o tests/Python3_Driver_Testing.md tests/py3_driver_testers.txt tests/model_stats.tsv makesupported: commands[2]> git diff --exit-code tests/Python3_Driver_Testing.md diff --git a/tests/Python3_Driver_Testing.md b/tests/Python3_Driver_Testing.md index 32a1e865..cb7631da 100644 --- a/tests/Python3_Driver_Testing.md +++ b/tests/Python3_Driver_Testing.md @@ -382,7 +382,8 @@ | <a name="Yaesu_FT-2800M"></a> Yaesu_FT-2800M | [Reported working](https://chirp.danplanet.com/issues/10616) | 05-Jun-2023 | Yes | 0.03% | | <a name="Yaesu_FT-2900R_1900R"></a> Yaesu_FT-2900R_1900R | [Reported working](https://chirp.danplanet.com/issues/10274) | 14-Jan-2023 | Yes | 0.05% | | <a name="Yaesu_FT-2900R_1900RTXMod_Opened_Xmit"></a> Yaesu_FT-2900R_1900RTXMod_Opened_Xmit | [Implied by Yaesu_FT-2900R_1900R](#user-content-Yaesu_FT-2900R_1900R) | 14-Jan-2023 | Yes | | -| <a name="Yaesu_FT-450D"></a> Yaesu_FT-450D | [@Old-Phart](https://github.com/Old-Phart) | 01-Jun-2023 | Yes | 0.01% | +| <a name="Yaesu_FT-450"></a> Yaesu_FT-450 | [Implied by Yaesu_FT-450D](#user-content-Yaesu_FT-450D) | 01-Nov-2023 | Yes | | +| <a name="Yaesu_FT-450D"></a> Yaesu_FT-450D | WCurlew | 01-Nov-2023 | Yes | 0.01% | | <a name="Yaesu_FT-4VR"></a> Yaesu_FT-4VR | [Implied by Yaesu_FT-4XE](#user-content-Yaesu_FT-4XE) | 24-Dec-2022 | Yes | 0.01% | | <a name="Yaesu_FT-4XE"></a> Yaesu_FT-4XE | Unit tested; needs confirm | 24-Dec-2022 | Yes | 0.14% | | <a name="Yaesu_FT-4XR"></a> Yaesu_FT-4XR | [Implied by Yaesu_FT-4XE](#user-content-Yaesu_FT-4XE) | 24-Dec-2022 | Yes | 0.11% | @@ -423,11 +424,11 @@ | <a name="Zastone_ZT-X6"></a> Zastone_ZT-X6 | [Implied by Retevis_RT22](#user-content-Retevis_RT22) | 9-Dec-2022 | Yes | 0.11% | ## Stats -**Drivers:** 420 +**Drivers:** 421 -**Tested:** 87% (367/53) (93% of usage stats) +**Tested:** 87% (368/53) (93% of usage stats) -**Byte clean:** 90% (380/40) +**Byte clean:** 90% (381/40) ## Meaning of this testing warning: in the working copy of 'tests/Python3_Driver_Testing.md', CRLF will be replaced by LF the next time Git touches it makesupported: exit 1 (0.12 seconds) C:\Users\wcurlew\Chirp> git diff --exit-code tests/Python3_Driver_Testing.md pid=11156 .pkg: _exit> python C:\Users\wcurlew\AppData\Local\Programs\Python\Python310\lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__ makesupported: FAIL code 1 (26.95=setup[25.37]+cmd[0.91,0.55,0.12] seconds) evaluation failed :( (27.52 seconds) C:\Users\wcurlew\Chirp>Microsoft Windows [Version 10.0.19045.3570] 'Microsoft' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>(c) Microsoft Corporation. All rights reserved. Microsoft was unexpected at this time. C:\Users\wcurlew\Chirp> C:\Users\wcurlew\Chirp>C:\Users\wcurlew>cd chirp 'C:\Users\wcurlew' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp> C:\Users\wcurlew\Chirp>C:\Users\wcurlew\Chirp>tox -e makesupported 'C:\Users\wcurlew\Chirp' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>.pkg: _optional_hooks> python C:\Users\wcurlew\AppData\Local\Programs\Python\Python310\lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__ '.pkg:' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>.pkg: get_requires_for_build_sdist> python C:\Users\wcurlew\AppData\Local\Programs\Python\Python310\lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__ '.pkg:' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>.pkg: get_requires_for_build_wheel> python C:\Users\wcurlew\AppData\Local\Programs\Python\Python310\lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__ '.pkg:' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>.pkg: prepare_metadata_for_build_wheel> python C:\Users\wcurlew\AppData\Local\Programs\Python\Python310\lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__ '.pkg:' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>.pkg: build_sdist> python C:\Users\wcurlew\AppData\Local\Programs\Python\Python310\lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__ '.pkg:' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>makesupported: install_package> python -I -m pip install --force-reinstall --no-deps C:\Users\wcurlew\Chirp\.tox\.tmp\package\107\chirp-0.tar.gz 'makesupported:' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>makesupported: commands[0]> python chirp/share/make_supported.py model_support.html 'makesupported:' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>makesupported: commands[1]> python tools/py3_driver_progress.py -o tests/Python3_Driver_Testing.md tests/py3_driver_testers.txt tests/model_stats.tsv 'makesupported:' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>makesupported: commands[2]> git diff --exit-code tests/Python3_Driver_Testing.md 'makesupported:' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>diff --git a/tests/Python3_Driver_Testing.md b/tests/Python3_Driver_Testing.md 'diff' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>index 32a1e865..cb7631da 100644 'index' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>--- a/tests/Python3_Driver_Testing.md '---' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>+++ b/tests/Python3_Driver_Testing.md '+++' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>@@ -382,7 +382,8 @@ '-382' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp> | <a name="Yaesu_FT-2800M"></a> Yaesu_FT-2800M | [Reported working](https://chirp.danplanet.com/issues/10616) | 05-Jun-2023 | Yes | 0.03% | | was unexpected at this time. C:\Users\wcurlew\Chirp> | <a name="Yaesu_FT-2900R_1900R"></a> Yaesu_FT-2900R_1900R | [Reported working](https://chirp.danplanet.com/issues/10274) | 14-Jan-2023 | Yes | 0.05% | | was unexpected at this time. C:\Users\wcurlew\Chirp> | <a name="Yaesu_FT-2900R_1900RTXMod_Opened_Xmit"></a> Yaesu_FT-2900R_1900RTXMod_Opened_Xmit | [Implied by Yaesu_FT-2900R_1900R](#user-content-Yaesu_FT-2900R_1900R) | 14-Jan-2023 | Yes | | | was unexpected at this time. C:\Users\wcurlew\Chirp>-| <a name="Yaesu_FT-450D"></a> Yaesu_FT-450D | [@Old-Phart](https://github.com/Old-Phart) | 01-Jun-2023 | Yes | 0.01% | < was unexpected at this time. C:\Users\wcurlew\Chirp>+| <a name="Yaesu_FT-450"></a> Yaesu_FT-450 | [Implied by Yaesu_FT-450D](#user-content-Yaesu_FT-450D) | 01-Nov-2023 | Yes | | < was unexpected at this time. C:\Users\wcurlew\Chirp>+| <a name="Yaesu_FT-450D"></a> Yaesu_FT-450D | WCurlew | 01-Nov-2023 | Yes | 0.01% | < was unexpected at this time. C:\Users\wcurlew\Chirp> | <a name="Yaesu_FT-4VR"></a> Yaesu_FT-4VR | [Implied by Yaesu_FT-4XE](#user-content-Yaesu_FT-4XE) | 24-Dec-2022 | Yes | 0.01% | | was unexpected at this time. C:\Users\wcurlew\Chirp> | <a name="Yaesu_FT-4XE"></a> Yaesu_FT-4XE | Unit tested; needs confirm | 24-Dec-2022 | Yes | 0.14% | | was unexpected at this time. C:\Users\wcurlew\Chirp> | <a name="Yaesu_FT-4XR"></a> Yaesu_FT-4XR | [Implied by Yaesu_FT-4XE](#user-content-Yaesu_FT-4XE) | 24-Dec-2022 | Yes | 0.11% | | was unexpected at this time. C:\Users\wcurlew\Chirp>@@ -423,11 +424,11 @@ '-423' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp> | <a name="Zastone_ZT-X6"></a> Zastone_ZT-X6 | [Implied by Retevis_RT22](#user-content-Retevis_RT22) | 9-Dec-2022 | Yes | 0.11% | | was unexpected at this time. C:\Users\wcurlew\Chirp> ## Stats '##' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp> C:\Users\wcurlew\Chirp>-**Drivers:** 420 '-**Drivers:**' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>+**Drivers:** 421 '+**Drivers:**' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp> C:\Users\wcurlew\Chirp>-**Tested:** 87% (367/53) (93% of usage stats) '-**Tested:**' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>+**Tested:** 87% (368/53) (93% of usage stats) '+**Tested:**' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp> C:\Users\wcurlew\Chirp>-**Byte clean:** 90% (380/40) '-**Byte' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>+**Byte clean:** 90% (381/40) '+**Byte' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp> C:\Users\wcurlew\Chirp> ## Meaning of this testing '##' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp> C:\Users\wcurlew\Chirp>warning: in the working copy of 'tests/Python3_Driver_Testing.md', CRLF will be replaced by LF the next time Git touches it 'warning:' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>makesupported: exit 1 (0.12 seconds) C:\Users\wcurlew\Chirp> git diff --exit-code tests/Python3_Driver_Testing.md pid=11156 'makesupported:' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp>.pkg: _exit> python C:\Users\wcurlew\AppData\Local\Programs\Python\Python310\lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__ '.pkg:' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp> makesupported: FAIL code 1 (26.95=setup[25.37]+cmd[0.91,0.55,0.12] seconds) 'makesupported:' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp> evaluation failed :( (27.52 seconds) 'evaluation' is not recognized as an internal or external command, operable program or batch file. C:\Users\wcurlew\Chirp> C:\Users\wcurlew\Chirp>C:\Users\wcurlew\Chirp>

2 1

[chirp_devel] TOX testing - potential unexpected condition?
by wcurlew＠juno.com 31 Oct '23

31 Oct '23

I've been working on the FT450d/450 changes, and was having issues getting through TOX. The problem was set and test special memories. On the FT450/450D, you can use the CLAR button to 'clear" a memory (which really just makes it not visible for the PMS memories), and the PMS upper and lower memories all allow this. In my test image, I have a couple of the PMS memories blanked out. In the FT450/D py get memory routines we set mem.empty = true to keep them from displaying on the gui. When the test_edges.py test_get_set_specials routine tries to set the special memories, it does not clear the mem.empty to False after reading what's already there. The FT450/D set special memory routines see an incoming request for an "empty" memory, and they make no changes and do not return a memory element. (as expected). The test_get_set_specials routine barfs on this, as the memory element returned is not what they expected. I added the m1.empty = False statement to the routine test_edges.py and the test now passes properly for the cleared memory. I ran a TOX with the full set of files in image and driver directories, and it screwed up 10 other radio models. While I would love for Chirp to accurately reflect what is on the radio, I'm concerned about perturbing the other radio models. (Just the testing obviously) Looking for comments/suggestions. Regards, Bill Result Test Duration Links Failed tests/test_drivers.py::TestCaseEdges_Icom_IC-U82::test_get_set_specials 222 ms Failed tests/test_drivers.py::TestCaseEdges_Icom_IC-E90_Radio::test_get_set_specials 00:00:02 Failed tests/test_drivers.py::TestCaseEdges_Kenwood_TM-D710G_CloneMode::test_get_set_specials 842 ms Failed tests/test_drivers.py::TestCaseEdges_Kenwood_TM-D710_CloneMode::test_get_set_specials 296 ms Failed tests/test_drivers.py::TestCaseEdges_Kenwood_TH-D74_clone_mode::test_get_set_specials 00:00:03 Failed tests/test_drivers.py::TestCaseEdges_Yaesu_FT-1D_R::test_get_set_specials 00:00:06 Failed tests/test_drivers.py::TestCaseEdges_Yaesu_FT-817ND_US::test_get_set_specials 00:00:02 Failed tests/test_drivers.py::TestCaseEdges_Yaesu_FT-857_897_US::test_get_set_specials 803 ms Failed tests/test_drivers.py::TestCaseEdges_Yaesu_FT3D_R::test_get_set_specials 00:00:07 Failed tests/test_drivers.py::TestCaseEdges_Yaesu_FT2D_R::test_get_set_specials

2 2

[chirp_devel] Ft450/450d driver changes
by wcurlew＠juno.com 30 Oct '23

30 Oct '23

Rick - The original author of the 450d code did not have a way of implementing the special data modes without changing the CHIRP_COMMON library. I also changed it to get my original 450 driver to work, and was properly chastised. So I came up with using the existing code "DIG" from common, and then putting together an mem.extra RS segment to hold the "extended" digital modes. This is working a treat for my FT-450, but now I need to see if I clobbered any of the 450D handling before submitting this. I'm not sure how to test the 450D backwards compatibility from a memory settings point of view. If you would like to see the driver prototype email me and I will send you my latest driver and a test img file for the FT450. Bill

2 1

[chirp_devel] RESOLVED Newbie to this, trouble with edits I think...
by wcurlew＠juno.com 29 Oct '23

29 Oct '23

I figured this out! During the processing of the special data_mode element in mem.extra, I was not testing to determine if the mode was moving between DIG and Non-DIG modes. The MEM.EXTRA data_mode processing when moving from a previous DIG mode going to a NON DIG mode always reset the _mode and _mode2 memories, which forced the mode column back to DIG. Now when I get a change to MODE, if it is non-DIG, I set the data_mode extra element to "N/A" When I get a DATA MODE change from N/A to any DIG mode, and the previous data_mode was "N/A", I force the mode to DIG In addition to solving my GUI entry problem, this way you never get an invalid combo of MODE and DATA MODE. What a pain! I've learned way to much more that I ever wanted to about how this stuff hangs together. Thanks for listening. Bill

2 1