New Model #7887
closedCRT Micron UV
Added by Tony Ling almost 4 years ago. Updated almost 4 years ago.
0%
Description
The official software for the CRT Micron absolutely stinks.
There is no facility to cut/paste, re-order or sort channels.
Three models CRT Micron / Retevis RT-95 / AnyTone AT-778, appear to be very similar as does the software although the non-CRT software 'sees' the Micron but will not read it reporting "Read Data Failed". The configuration files (.dat) do not appear to fully open between brands stating Wrong model type. A sample .dat file for the Micron is included.
These radios are believed to be Qixiang in origin.
Files
| CRT-Micron-UV_B2_Amateur_003.dat (44.7 KB) CRT-Micron-UV_B2_Amateur_003.dat | Tony Ling, 05/17/2020 01:26 PM | ||
| 20200522_anytone778uv.py (30.1 KB) 20200522_anytone778uv.py | Joe Milbourn, 05/22/2020 02:39 PM | ||
| debug_20200526_1510.txt.log (51.8 KB) debug_20200526_1510.txt.log | Tony Ling, 05/26/2020 07:23 AM |
Related issues
Updated by Bernhard Hailer almost 4 years ago
- Subject changed from CRT Micron-UV to CRT Micron UV
Updated by Joe Milbourn almost 4 years ago
- File 20200522_anytone778uv.py 20200522_anytone778uv.py added
I think the new AnyTone 778UV driver will support his radio, but the current version won't automatically detect it. However, I don't have this model to hand to try it out.
If you, or anyone else, would be willing to have a go a very experimental driver is attached - 20200522_anytone778uv.py. To load it into your chirp:
Download 20200522_anytone778uv.py and put it somewhere convienent, doesn't matter where.¶
Start Chirp and select 'Enable Developer Functions' from the 'Help' menu¶
From the 'File' menu select 'Load Module' and browse to wherever you saved 20200522_anytone778uv.py and select it.¶
The chirp window will go red - that's OK.¶
With your radio connected, choose 'Download from radio' from the 'Radio' menu, and specify your serial port. Choose 'CRT' as the manufacturer, and 'Micron UV' as the model, then hit OK.¶
Chirp will warn you that this is an experimental driver, say yes if you want to continue.¶
Hopefully, you'll see the 'Cloning from radio...' progress bar, and after a while you'll see all your memories in chirp. If you see an error, please attach a screenshot here.¶
Either way, please post your results here.
Thank you!
Updated by Robke Onbekend almost 4 years ago
Great job Joe,
I tested the expired driver 20200522_anytone778uv.py on my CRT Micron UV, on port COM5. Read; no errors and correct data received. Number of channels filled with new data and written back to the CRT Micron UV; here too no errors and data has been written correctly.
The 'Cloning from radio ...' progress bar also works as it should, both in CHIRP and on the CRT Micron UV. After downloading to the CRT Micron UV, the CRT Micron UV is restarted with the newly loaded date, just like in the CRT software.
This expository driver seems to work well for the CRT Micron UV.
Updated by Robke Onbekend almost 4 years ago
expired driver and expository driver must been read as experimental driver.
Updated by Tony Ling almost 4 years ago
Windows 10, CHIRP 20200521 and 20200522_anytone778uv.py
All appears well. Read, save and wright working fine.
Many thanks for your endeavours Joe.
Updated by Tony Ling almost 4 years ago
Ubuntu MATE 20.04, CHIRP 20200521 and 20200522_anytone778uv.py
No CRT models appear in the manufacturer / model dialogue prior to read, just the Anytone AT-778UV which rejects the CRT Micron UV
chirpw
WARNING: python-future package is not available; chirp.drivers.anytone778uv requires it
WARNING: python-future package is not available; chirp.drivers.ga510 requires it
WARNING: python-future package is not available; chirp.drivers.tk8180 requires it
(process:73387): Gtk-WARNING **: 15:40:34.166: Locale not supported by C library.
Using the fallback 'C' locale.
WARNING: python-future package is not available; chirp.ui.mainapp requires it
ERROR: -- Exception: --
ERROR: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/chirp/ui/clone.py", line 256, in run
self.__radio.sync_in()
File "/usr/lib/python2.7/dist-packages/chirp/drivers/anytone778uv.py", line 483, in sync_in
self._mmap = do_download(self)
File "/usr/lib/python2.7/dist-packages/chirp/drivers/anytone778uv.py", line 302, in do_download
raise e
RadioError: Radio version 'IMICRONV100' not in allowed list
ERROR: ----------------
ERROR: Clone failed: Radio version 'IMICRONV100' not in allowed list
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/chirp/ui/mainapp.py", line 505, in cb_clonein
d = inputdialog.ExceptionDialog(emsg)
File "/usr/lib/python2.7/dist-packages/chirp/ui/inputdialog.py", line 89, in __init__
self.format_secondary_text(str(exception))
TypeError: GtkMessageDialog.format_secondary_text() argument 1 must be string without null bytes or None, not str
Updated by Joe Milbourn almost 4 years ago
Tony Ling wrote:
Ubuntu MATE 20.04, CHIRP 20200521 and 20200522_anytone778uv.py
Thanks for testing Tony, great to hear it works, at least on Windows. On your linux install, you might try installing the python-future package and see if that fixes things.
Updated by Tony Ling almost 4 years ago
Windows 10, CHIRP 20200521 and 20200522_anytone778uv.py
CHIRP under CRT Micron UV will not accept frequency entries outside 144 - <148MHz and 430 - <450MHz
The Micron model is capable of 136-174MHz and 400 - 490MHz when in Band 2 FW mode.
CHIRP fails to read correct channel spacing from DUT.
CHIRP fails to retrieve channel spacing value from file.
CHIRP fails to retrieve RF power value from file
Updated by Tony Ling almost 4 years ago
Hyphen '-' not accepted as valid text character in name (alpahatag) field
Updated by Joe Milbourn almost 4 years ago
Tony Ling wrote:
Windows 10, CHIRP 20200521 and 20200522_anytone778uv.py
CHIRP under CRT Micron UV will not accept frequency entries outside 144 - <148MHz and 430 - <450MHz
The Micron model is capable of 136-174MHz and 400 - 490MHz when in Band 2 FW mode.
Yes, at the moment that's correct. Still working out how the radio tells the programming software what band is enabled so we can programme correctly.
CHIRP fails to read correct channel spacing from DUT.
CHIRP fails to retrieve channel spacing value from file.
The driver maps channel width to mode, FM for 25kHz and NFM for 12.5kHz, with no option for the 20kHz also supported by the radio. Is that what you refer to? At the moment I map 20kHz to FM (so 25kHz) on downloading from the radio and only programme 12.5kHz or 25kHz channels to the radio.
CHIRP fails to retrieve RF power value from file
I don't see that here, please could you add a bit more detail about how to reproduce it, and the chirp debug.log showing it happen? See How_To_Report_Issues for how to get the debug log.
Hyphen '-' not accepted as valid text character in name (alpahatag) field
That one's easy, fixed, thank you.
Thanks or spending the time to try this out, much appreciated.
Updated by Joe Milbourn almost 4 years ago
Joe Milbourn wrote:
Tony Ling wrote:
CHIRP fails to retrieve RF power value from file
I don't see that here, please could you add a bit more detail about how to reproduce it, and the chirp debug.log showing it happen? See How_To_Report_Issues for how to get the debug log.
Scratch that, I do see something here where I set the power to high, send it to the radio, read it back, and get low. Other power settings work fine. If that's what you saw, good spot, and now fixed.
Updated by Tony Ling almost 4 years ago
Thanks again Joe for your reply,
It seems I misunderstood the Tune Step function. This of course is a global setting which affects only VCO and is not used on a channel-by-channel basis. I have now hidden that column.
OK on the channel bandwidth issue too.
The RF power level is for me more immediate than it having been programmed to the radio and read.
The methodology is as follows.
A test file is opened
The first line (Loc 0) is edited from Low to High.
The file is saved
The file is closed
The file is re-opened and it is noted that the value 'Low' now appears. This can be repeated also with the 'Medium' value
A debug log (debug_20200526_1510.txt)is attached
Thanks for the hyphen. You are probably aware but the underscore is also available in the front panel FW interface.
Regards,and again, all your hard work is very much appreciated.
Updated by Tony Ling almost 4 years ago
Tony Ling wrote: (#10)
Hyphen '-' not accepted as valid text character in name (alpahatag) field
Resolved in Daily 20200603
Many thanks Joe
Updated by Tony Ling almost 4 years ago
A very minor issue, the underscore '_' is also a valid character in the firmware's character set.
Updated by Joe Milbourn almost 4 years ago
Tony Ling wrote:
A very minor issue, the underscore '_' is also a valid character in the firmware's character set.
Tony - I'd not ignored your comment about '' previously, however I can't make it work! I can't create a name with '' in from the front panel, I can't create one from the AnyTone software, and (having allowed it in chirp) when I do create one in chirp I see a ' ' on the radio front panel.
How are you getting your '_'?
Updated by Tony Ling almost 4 years ago
My apologies Joe, I misunderstood the fact that a space is represented by an underscore in the device's formware. I should have investigated further before posting my comment.
I will try to be more thorough in future in order to improve the signal to noise ratio.
Updated by Bernhard Hailer almost 4 years ago
- Status changed from New to Closed
Implementation appears to be complete.