[chirp_devel] [PATCH 0 of 4] Make ft857 survive to run_tests
The following patches has to be applied on top of 857 ones I sent, here is also included the merge with Dan's changes in the repository. After all this ft857 can pass the run_test.
73 de IZ3GME Marco
P.s. Hope all this work as this is my first try sending patch directly via email ...
# HG changeset patch # User Marco Filippi iz3gme.marco@gmail.com # Date 1327136373 -3600 # Node ID 70facf402fea4c7ef1742c22a20914845b0021d7 # Parent f88a7674686e21a04ed74861bcbf9806bb753a21 Add "valid_cross_modes" to RadioFeatures.
diff -r f88a7674686e -r 70facf402fea chirp/chirp_common.py --- a/chirp/chirp_common.py Thu Jan 19 23:03:51 2012 +0100 +++ b/chirp/chirp_common.py Sat Jan 21 09:59:33 2012 +0100 @@ -548,6 +548,7 @@ "valid_power_levels" : [], "valid_characters" : "", "valid_name_length" : 0, + "valid_cross_modes" : [],
"has_sub_devices" : BOOLEAN, "memory_bounds" : (0, 0), @@ -647,6 +648,8 @@ self.init("valid_name_length", 6, "The maximum number of characters in a memory's " + "alphanumeric tag") + self.init("valid_cross_modes", list(CROSS_MODES), + "Supported tone cross modes")
self.init("has_sub_devices", False, "Indicates that the radio behaves as two semi-independent " + @@ -764,6 +767,11 @@ if rf.valid_tmodes and mem.tmode not in rf.valid_tmodes: msg = ValidationError("Tone mode %s not supported" % mem.tmode) msgs.append(msg) + else: + if mem.tmode == "Cross": + if rf.valid_cross_modes and mem.cross_mode not in rf.valid_cross_modes: + msg = ValidationError("Cross tone mode %s not supported" % mem.cross_mode) + msgs.append(msg)
if rf.valid_duplexes and mem.duplex not in rf.valid_duplexes: msg = ValidationError("Duplex %s not supported" % mem.duplex) diff -r f88a7674686e -r 70facf402fea chirpui/memedit.py --- a/chirpui/memedit.py Thu Jan 19 23:03:51 2012 +0100 +++ b/chirpui/memedit.py Sat Jan 21 09:59:33 2012 +0100 @@ -1248,6 +1248,7 @@ self.choices[_("Bank")] = gtk.ListStore(TYPE_STRING, TYPE_STRING) self.choices[_("Mode")] = features["valid_modes"] self.choices[_("Tone Mode")] = features["valid_tmodes"] + self.choices[_("Cross Mode")] = features["valid_cross_modes"] self.choices[_("Skip")] = features["valid_skips"] self.choices[_("Power")] = [str(x) for x in features["valid_power_levels"]]
# HG changeset patch # User Marco Filippi iz3gme.marco@gmail.com # Date 1327136434 -3600 # Node ID 34c073c6188ca02caa543dd58271b84c899ec55e # Parent 70facf402fea4c7ef1742c22a20914845b0021d7 Set valid_cross_modes as needed
diff -r 70facf402fea -r 34c073c6188c chirp/ft857.py --- a/chirp/ft857.py Sat Jan 21 09:59:33 2012 +0100 +++ b/chirp/ft857.py Sat Jan 21 10:00:34 2012 +0100 @@ -109,7 +109,7 @@ rf = ft817.FT817Radio.get_features(self) rf.has_cross = True rf.valid_tmodes = self.TMODES_REV.keys() - # rf.valid_cross_mode = CROSS_MODES_REV.keys() # TODO will do this later + rf.valid_cross_modes = self.CROSS_MODES_REV.keys() return rf
def get_duplex(self, mem, _mem):
# HG changeset patch # User Marco Filippi iz3gme.marco@gmail.com # Date 1327136565 -3600 # Node ID 60adc5361b16d92da084e775480549bb798c0505 # Parent 34c073c6188ca02caa543dd58271b84c899ec55e # Parent 7b748c5c5f6584928431950726fe9a62be900fda merge
diff -r 34c073c6188c -r 60adc5361b16 chirpui/mainapp.py --- a/chirpui/mainapp.py Sat Jan 21 10:00:34 2012 +0100 +++ b/chirpui/mainapp.py Sat Jan 21 10:02:45 2012 +0100 @@ -867,6 +867,22 @@ devaction = self.menu_ag.get_action("viewdeveloper") devaction.set_visible(action.get_active())
+ def do_change_language(self): + langs = ["Auto", "English", "Polish"] + d = inputdialog.ChoiceDialog(langs, parent=self, + title="Choose Language") + d.label.set_text(_("Choose a language or Auto to use the " + "operating system default. You will need to " + "restart the application before the change " + "will take effect")) + d.label.set_line_wrap(True) + r = d.run() + if r == gtk.RESPONSE_OK: + print "Chose language %s" % d.choice.get_active_text() + conf = config.get() + conf.set("language", d.choice.get_active_text(), "state") + d.destroy() + def mh(self, _action, *args): action = _action.get_name()
@@ -912,6 +928,8 @@ "move_up", "move_dn", "exchange", "devshowraw", "devdiffraw"]: self.get_current_editorset().memedit.hotkey(_action) + elif action == "language": + self.do_change_language() else: return
@@ -951,6 +969,7 @@ <menuitem action="devshowraw"/> <menuitem action="devdiffraw"/> </menu> + <menuitem action="language"/> </menu> <menu action="radio" name="radio"> <menuitem action="download"/> @@ -992,6 +1011,7 @@ ('viewdeveloper', None, _("Developer"), None, None, self.mh), ('devshowraw', None, _('Show raw memory'), "<Control><Shift>r", None, self.mh), ('devdiffraw', None, _("Diff raw memories"), "<Control><Shift>d", None, self.mh), + ('language', None, _("Change language"), None, None, self.mh), ('radio', None, _("_Radio"), None, None, self.mh), ('download', None, _("Download From Radio"), "<Alt>d", None, self.mh), ('upload', None, _("Upload To Radio"), "<Alt>u", None, self.mh), diff -r 34c073c6188c -r 60adc5361b16 chirpw --- a/chirpw Sat Jan 21 10:00:34 2012 +0100 +++ b/chirpw Sat Jan 21 10:02:45 2012 +0100 @@ -17,6 +17,7 @@
from chirp import platform, CHIRP_VERSION +from chirpui import config
# Hack to setup environment platform.get_platform() @@ -45,6 +46,17 @@ if not os.path.exists(localepath): localepath = "/usr/share/chirp/locale"
+conf = config.get() +manual_language = conf.get("language", "state") +if manual_language and manual_language != "Auto": + lang_codes = { "English" : "en_US", + "Polish" : "pl", + } + try: + os.environ["LANG"] = lang_codes[manual_language] + except KeyError: + print "Unsupported language `%s'" % manual_language + langs = [] lc, encoding = locale.getdefaultlocale() if (lc): diff -r 34c073c6188c -r 60adc5361b16 tests/run_tests --- a/tests/run_tests Sat Jan 21 10:00:34 2012 +0100 +++ b/tests/run_tests Sat Jan 21 10:02:45 2012 +0100 @@ -261,8 +261,8 @@ for tmode in rf.valid_tmodes: if tmode not in chirp_common.TONE_MODES: continue - elif tmode in ["DTCS", "DTCS-R"]: - continue # We'll test DCS separately + elif tmode in ["DTCS", "DTCS-R", "Cross"]: + continue # We'll test DCS and Cross tones separately
m.tmode = tmode if tmode == "": @@ -301,6 +301,15 @@ m.dtcs_polarity = pol self.set_and_compare(m)
+ def do_cross(self, m, rf): + if not rf.has_cross: + return + + m.tmode = "Cross" + for cross_mode in chirp_common.CROSS_MODES: + m.cross_mode = cross_mode + self.set_and_compare(m) + def do_duplex(self, m, rf): for duplex in rf.valid_duplexes: if duplex not in ["", "-", "+", "split"]: @@ -351,6 +360,7 @@
self.do_tone(clean_mem(), rf) self.do_dtcs(clean_mem(), rf) + self.do_cross(clean_mem(), rf) self.do_duplex(clean_mem(), rf) self.do_skip(clean_mem(), rf) self.do_mode(clean_mem(), rf)
# HG changeset patch # User Marco Filippi iz3gme.marco@gmail.com # Date 1327137183 -3600 # Node ID a952608d9724bcd9ccdd7b7c1bea02dc5cf01ca4 # Parent 60adc5361b16d92da084e775480549bb798c0505 Use valid_cross_modes during test
diff -r 60adc5361b16 -r a952608d9724 tests/run_tests --- a/tests/run_tests Sat Jan 21 10:02:45 2012 +0100 +++ b/tests/run_tests Sat Jan 21 10:13:03 2012 +0100 @@ -306,7 +306,7 @@ return
m.tmode = "Cross" - for cross_mode in chirp_common.CROSS_MODES: + for cross_mode in rf.valid_cross_modes: m.cross_mode = cross_mode self.set_and_compare(m)
Hi Marco,
The following patches has to be applied on top of 857 ones I sent, here is also included the merge with Dan's changes in the repository. After all this ft857 can pass the run_test.
Thanks! I did some work on the tests to handle radios that use cross mode so that you could get the ft857 to pass :)
Note that it's very unconventional to send a merge changeset like this to a maintainer in email. Since my tree already has those changes, it won't apply for me. This is because you're committing changes directly to your tree and pulling from the repository, which is fine but has this other little snag.
When you do your "hg email" you should just skip the merge changeset. If the merge was non-trivial, then you really should rebase your patches on top of the current tree. The "mq" extension to hg makes this really easy to do.
Anyway, I'll fix and apply these patches as they are this time. Are we confident that the 857 driver is ready? I haven't seen a report from anyone else (David?) that they have been successful and I don't have an 857 to test with.
Thanks!
Hello Everyone,
Anyway, I'll fix and apply these patches as they are this time. Are we confident that the 857 driver is ready? I haven't seen a report from anyone else (David?) that they have been successful and I don't have an 857 to test with.
I quickly tried to apply the patches but they weren't applying cleanly and since the patches were given over email vs. committed directly to the repository, I thought I'd wait a bit before complaining. :-) I assume everything is in the repository now so I'll try again later today.
--David
I quickly tried to apply the patches but they weren't applying cleanly and since the patches were given over email vs. committed directly to the repository, I thought I'd wait a bit before complaining. :-)
No, nearly every open source project on the planet communicates these changes over email in patch format. His patch emails are clean, and they work fine. Since you're using thunderbird, you can hit Control-U on each mail and save the uuber-raw version, which should apply. Note, don't apply his "merge" patch, but all the rest.
I assume everything is in the repository now so I'll try again later today.
No, I was waiting for you to apply and test before I committed them.
Thanks!
Hello Macro, Dan,
Here are my initial results. As you can see, a bit more work needs to be done. If you need me to do some additional tests, please let me know. Maybe running it with a
CHIRP_DEBUG=y ./chirpw 2>&1 | tee debug.log
--David
With a patched 0.1.13dev running on Centos 6.2 with an RT-Systems FTDI-based USB cable - GTK 2.18.9 - PyGTK 2.16.0 - Python 2.6.6
If I configured chirp and it sat there waiting for a while (30 seconds) without starting the Clone on the radio, it eventually throws an error: -- CHIRP 0.1.13dev on Linux - CentOS release 6.2 (Final)Kernel \r on an \m (Python 2.6.6) Clone thread started -- Exception: -- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/clone.py", line 223, in run self.__radio.sync_in() File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirp/ft817.py", line 180, in sync_in self._mmap = clone_in(self) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirp/ft817.py", line 59, in clone_in data += ft817_read(pipe, block, blocks) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirp/ft817.py", line 37, in ft817_read raise Exception("Unable to read block %02X expected %i got %i" % (blocknum, block+2, len(data))) Exception: Unable to read block 00 expected 4 got 0 ------ Clone failed: Unable to read block 00 expected 4 got 0 Clone thread ended --- Exception Dialog: Unable to read block 00 expected 4 got 0 --- None
A chirpw timeout was expected but the user dialog box on the GUI should be made to be less cryptic
----------------------------
If I tried again, with starting the Cloning on the radio, the cloning image begins to go to to Chirp but at the end, the radio says "Clone mode: ERROR" though Chirp seems to be happy:
Clone thread started Clone completed in 12 seconds Clone thread ended Starting memedit 'NoneType' object has no attribute 'split' Bank Index supported: False Bank supported: False DTCS Code supported: True DTCS Pol supported: False Mode supported: True Offset supported: True Name supported: True Tune Step supported: True Name supported: True ToneSql supported: False Cross Mode supported: True Started
-------------------
Looking in the resulting Chirp GUI, the downloaded memories look ok except
no power levels were saved. Maybe this isn't saved on a per-memory basis?
I don't see any of the HOME memories in the GUI
I don't see any Memory group support in the GUI: valid groups a "Ma" through "Mj" -- need to test more as I didn't have any
Did not try the split memory yet -- need to test as I didn't have any
------------------
Saving the download image to a file works. Closing Chirp down, restarting it, and opening up the saved image works properly
------------------
Sending from Chirp to the radio
Transfer starts and seems to run fine up until the 99% mark:
Chirp completes yet the FT857 is stuck where the radio's LCD shows a "full download bar" saying "clone mode: Sending" yet it never completes
Had to turn off radio to exit the "Sending" screen
Upon restart, all memories and FT857 system settings were lost --> Sure would be nice if the program could also handle the higher level menu settings at lease just as a binary blob and allow to be able to restore or not-restore that when uploading back to the radio
This seems to be the same behavior that Kurt KC9LDH saw with his FT-817
----------------- Misc
In the Radio dialog, it's not remembering the last serial port I used. Specifically, I have my port named via UDEV as /dev/ft857_prog
Chirp About --> Credits doesn't show Marco
On 27/01/2012 00:04, David Ranch wrote:
Hello Macro, Dan,
Here are my initial results. As you can see, a bit more work needs to be done. If you need me to do some additional tests, please let me know.
Thanks David for your precise report
If I configured chirp and it sat there waiting for a while (30 seconds) without starting the Clone on the radio, it eventually throws an error:
[...cut...]
A chirpw timeout was expected but the user dialog box on the GUI should be made to be less cryptic
Ok, the exception is more developer than user oriented right now, will change it at least for the first block
If I tried again, with starting the Cloning on the radio, the cloning image begins to go to to Chirp but at the end, the radio says "Clone mode: ERROR" though Chirp seems to be happy:
This is not good: it means that the radio was expecting a ACK which never arrived (or which has been lost). I have to investigate this.
Looking in the resulting Chirp GUI, the downloaded memories look ok except
good news good news, i need good news ;)
no power levels were saved. Maybe this isn't saved on a per-memory basis?
Right, as far as I know they are saved per-band
I don't see any of the HOME memories in the GUI
Righ, only regular memories are supported (as of today)
I don't see any Memory group support in the GUI: valid groups a "Ma" through "Mj" -- need to test more as I didn't have any
memory group are not supported (yet)
Did not try the split memory yet -- need to test as I didn't have any
This is the area that needs most of investigation.
Sending from Chirp to the radio
Transfer starts and seems to run fine up until the 99% mark:
Chirp completes yet the FT857 is stuck where the radio's LCD shows a "full download bar" saying "clone mode: Sending" yet it never completes
I would not expect it to work after the failure during clone in. There must be a packet more than expected ...
Had to turn off radio to exit the "Sending" screen
Upon restart, all memories and FT857 system settings were lost
I'm sorry, I should warn you not to clone back to radio if the clone in operation does not finish correctly.
--> Sure would be nice if the program could also handle the higher level menu settings at lease just as a binary blob and allow to be able to restore or not-restore that when uploading back to the radio
The clone operation has no option: it simply send the whole memory of the radio. We change the content of the memories area but the rest of the blob is left as is, eg this the reason for wich you have to start with a clone.
This seems to be the same behavior that Kurt KC9LDH saw with his FT-817
Right: seems that in both case we have clone protocol errors. I will investigate Kurt log and see if I found something interesting.
Misc
In the Radio dialog, it's not remembering the last serial port I used. Specifically, I have my port named via UDEV as /dev/ft857_prog
Dan, can you take a look at this?
Chirp About --> Credits doesn't show Marco
You are so precise in testing you scares me ;) Thanks
73 de IZ3GME Marco
Hello Marco,
Did not try the split memory yet -- need to test as I didn't have any
This is the area that needs most of investigation.
Ok.. I'll play with that a bit.
Had to turn off radio to exit the "Sending" screen Upon restart, all memories and FT857 system settings were lost
I'm sorry, I should warn you not to clone back to radio if the clone in operation does not finish correctly.
This might be a worthwhile popup on Chirp. Once the download is complete, post a dialog box saying something like "Download Complete! Did the FT857 finish it's upload? Yes | No". If yes, the the program goes to the main menu. If No, post a text box saying "Something must have gone wrong. Please review what memories were downloaded into Chirp and send an email to the Chirp email list about this. DO NOT use Chirp to upload memories to your radio if the download failed. You risk resetting all your memories otherwise though the radio will be fine"
The clone operation has no option: it simply send the whole memory of the radio. We change the content of the memories area but the rest of the blob is left as is, eg this the reason for wich you have to start with a clone.
So are you saying that if I have a set of fully altered Main menu settings (color, power levels, CW ID, etc), I download it with Chirp, I then factory reset my radio, and then upload from Chirp to the radio, I'll get back all my Main menu settings?
This seems to be the same behavior that Kurt KC9LDH saw with his FT-817
Right: seems that in both case we have clone protocol errors. I will investigate Kurt log and see if I found something interesting.
Ok... Let me know if you need anything else on my side.
You are so precise in testing you scares me ;)
I don't know how to do it any other way. Is there an easier way? ;-)
--David
Hi David
This might be a worthwhile popup on Chirp. Once the download is complete, post a dialog box saying something like "Download Complete! Did the FT857 finish it's upload? Yes | No". If yes, the the program goes to the main menu. If No, post a text box saying "Something must have gone wrong. Please review what memories were downloaded into Chirp and send an email to the Chirp email list about this. DO NOT use Chirp to upload memories to your radio if the download failed. You risk resetting all your memories otherwise though the radio will be fine"
This is something we can do, let's see what Dan think about that. BTW it would be MUCH better having yaesu make a robust and public protocol.
So are you saying that if I have a set of fully altered Main menu settings (color, power levels, CW ID, etc), I download it with Chirp, I then factory reset my radio, and then upload from Chirp to the radio, I'll get back all my Main menu settings?
This is what I suppose even if I didn't had a look at the rest of the data (yet), the clone operation should replicate all setting of the radio. Having a full backup of the radio is one of the reasons for which I decided to use the clone protocol instead of peeking and poking in memory.
This seems to be the same behavior that Kurt KC9LDH saw with his FT-817
Right: seems that in both case we have clone protocol errors. I will investigate Kurt log and see if I found something interesting.
Ok... Let me know if you need anything else on my side.
Please run the attached script and send me the output: - copy the file to your chirp-devel directory in the chirp subdir (the same where the ft857.py file is) - cd to that dir - prepare the radio for the clone operation - run it with python ./dump857.py /dev/ft857_prog 2>&1 >/tmp/857dump - start radio clone tx wait for the clone to complete, the radio should complain "as usual" and the program should take a few seconds to finish after the actual data transfer is ended. Send the generated /tmp/857dump file. Plese send also an image of the white label on the radio (the one with model, serial number etc): we have to find not only the protocol details but also a way to recognize the various radio sub models.
Thank for your help
73 de IZ3GME Marco
Hello Marco,
First off, thanks for taking the time to troubleshoot this and I'm sure that many people will love to have FT support in Chirp!
BTW it would be MUCH better having yaesu make a robust and public protocol.
Yeah... I don't think that will happen. I get the impression that the protocol that Kenwood is much more flexible but I don't know if it's open per se. Curious, have you ever spoke to some of the other programming tool people out there such as G4HFQ with his FT programs? http://www.g4hfq.co.uk/mmohelp/mmohelp.htm All of those are very nice but being Windows only, they won't work for me.
This is what I suppose even if I didn't had a look at the rest of the data (yet), the clone operation should replicate all setting of the radio. Having a full backup of the radio is one of the reasons for which I decided to use the clone protocol instead of peeking and poking in memory.
Right.. ok. That's good. What would be SLICK is that, (if ever) that Chirp could download three FT857 radios and save the main binary blobs for the primary radio settings as say radio A, B, C. When programming in back the main memories, ask the user if they want to substitute in the correct radio's main menu settings with those memories. It seems this would be possible considering that Chirp already knows where the memories go w/o disturbing the main radio settings.
Send the generated /tmp/857dump file.
Will send in another email directly to you.
--David
Curious, have you ever spoke to some of the other programming tool people out there such as G4HFQ with his FT programs? http://www.g4hfq.co.uk/mmohelp/mmohelp.htm All of those are very nice but being Windows only, they won't work for me.
For me neither ;)
Experience says that people which sell programs don't really like to share informations that can result in others making similar products ... but I must admit I don't even try with G4HFQ. I have some ideas to discuss with Dan and than may be we can try to ask G4HFQ.
Right.. ok. That's good. What would be SLICK is that, (if ever) that Chirp could download three FT857 radios and save the main binary blobs for the primary radio settings as say radio A, B, C. When programming in back the main memories, ask the user if they want to substitute in the correct radio's main menu settings with those memories. It seems this would be possible considering that Chirp already knows where the memories go w/o disturbing the main radio settings.
Well ... hope Dan will confirm but I suppose that this is far from chirp objective. Really taking care of all radio settings is an enormous work from my point of view. As of today you can already save from ft857 A and copy to ft857 B (I mean whole image not only memories) *but only if* they are the very same sub model otherwise ... radio B will refuse the image and reset to default (you know the story ;) )
I received your dump, as I anticipated there is simply a packet more than program expect. A two second patch should solve the concrete problem but the real problem is how we can distinguish between my ft857 sub model and your one. Did you bought it as a simple/old 857 or a 857/d or what else? The only interesting info I see on the label is that your one is "FCC approved" while mine is "CE".
Thanks for your time
73 de IZ3GME Marco
Hello Marco,
Did you bought it as a simple/old 857 or a 857/d or what else? The only interesting info I see on the label is that your one is "FCC approved" while mine is "CE".
I bought this radio used as a FT857D.
I wonder if there is a Tech menu on these units that can give us more info. Looking on the mods.dk site, there might be but I used up view for the day: http://www.mods.dk/view.php?ArticleId=2731
Uploaded Description 28-10-2011 Fix for FT?]857/?]897: S9 crashes in receiver, with or without antenna attached. http://www.mods.dk/view.php?ArticleId=4841 05-07-2010 LDG AT100 Y-ACC cable for FT-857 and FT-897 http://www.mods.dk/view.php?ArticleId=4625 29-06-2010 Ground connection for FT-857. http://www.mods.dk/view.php?ArticleId=4622 06-12-2009 Wide banding the FT-817 857 897 by CAT interface. http://www.mods.dk/view.php?ArticleId=4480 06-12-2009 FT-857 (D) Allignment settings http://www.mods.dk/view.php?ArticleId=4478 11-11-2008 CAT Interface / Programmer for FT-857D http://www.mods.dk/view.php?ArticleId=4242 08-11-2008 Flashing Display for Yaesu FT-857D http://www.mods.dk/view.php?ArticleId=4240 05-11-2007 Keying the SB200 Amplifier http://www.mods.dk/view.php?ArticleId=3970 16-08-2007 Wideband ESSB filter modification for FT-857D and FT-897D http://www.mods.dk/view.php?ArticleId=3914 20-11-2006 FT897/857 TX Extention 40m Band and ARS by Software http://www.mods.dk/view.php?ArticleId=3648 19-11-2006 Bad reception on one or several bands. http://www.mods.dk/view.php?ArticleId=3646 23-09-2006 Key click modification for FT857D http://www.mods.dk/view.php?ArticleId=3601 20-09-2006 Issues with the Yaesu FT857D http://www.mods.dk/view.php?ArticleId=3598 08-04-2006 CAT cable for Yaesu http://www.mods.dk/view.php?ArticleId=3468 23-01-2006 Changing the RF-Driver Transistors FT-857, FT-897 http://www.mods.dk/view.php?ArticleId=3336 12-06-2005 FT857 and FT857D low frequency response in SSB http://www.mods.dk/view.php?ArticleId=3195 20-03-2005 40m band expansion for 7.1mhz to 7.2mhz transmit for FT-857 http://www.mods.dk/view.php?ArticleId=3156 03-02-2005 TX Power Mod for Yaesu FT857(D) http://www.mods.dk/view.php?ArticleId=3135 23-01-2005 Yaesu FT-857/897 FM-Squelch Fix http://www.mods.dk/view.php?ArticleId=3130 15-08-2004 FT-857 Undocumented Feature http://www.mods.dk/view.php?ArticleId=3054 31-12-2003 FT-857 Mic wiring http://www.mods.dk/view.php?ArticleId=2913 21-12-2003 Adding drag to FT-857's tuning knob http://www.mods.dk/view.php?ArticleId=2897 23-11-2003 FT-857 European FM Settings http://www.mods.dk/view.php?ArticleId=2869 09-08-2003 FT897/857/817 Jumpers by Software http://www.mods.dk/view.php?ArticleId=2805 23-04-2003 Second menu for FT-857 http://www.mods.dk/view.php?ArticleId=2731 06-04-2003 Installing The FT-857 Options http://www.mods.dk/view.php?ArticleId=2719 06-04-2003 MARS mod of the FT-857 http://www.mods.dk/view.php?ArticleId=2717
--David
Hi David
I bought this radio used as a FT857D.
AHAaaa!! Here we are! This is good! I will make a patch to support FT857D later today.
BTW can't we arrange an online meeting on irc so you can test on fly the changes?
I'll be connected today since 14 utc up to 20 utc.
I wonder if there is a Tech menu on these units that can give us more info.
It would be too easy ;) And as you can see they don't even have any readable useful info on the label ...
Looking on the mods.dk site, there might be but I used up view for the day: http://www.mods.dk/view.php?ArticleId=2731
I'll take a look to mods.dk later today
73 de IZ3GME Marco
Hello Marco,
I bought this radio used as a FT857D.
AHAaaa!! Here we are! This is good! I will make a patch to support FT857D later today.
Ok... I wouldn't have thought that the D would have changed the CAT protocol any. From my understanding, the D only included the TCXO-9 high stability crystal but I'm not 100% sure on that.
BTW can't we arrange an online meeting on irc so you can test on fly the changes?
I'll be connected today since 14 utc up to 20 utc.
Sure.. I'll send you my IM details in another email.
--David
01/31/2012
FT857D -- - Download now works!
- Menu item should show "FT-857D (US Model)" - (notice the additional "D" - I have no idea if this code will work for a FT-857 non-D (US model)
- Saving the downloaded image to the local hard drive works
- When loading the saved image via the Chirp menus:
- Chirp initially says "Unable to detect model!"
- In IM'ing with Marco, it seems that Chirp detects (more like guesses) the radio model based upon the saved image file size! This is not going to be reliable. I'd argue that Chirp should either prepend a signature in the .img file or it should create an associated meta file with the same name as the .img file that contains details about the image (radio vendor, model, etc.)
- When I selected Chirp upload FIRST and then went to RX on the FT857, the Chirp upload menu went away too quickly. Tried again but more quickly and the upload went ok!
VX5 -- Won't clone with chirp-hg-c00282ce90f6 - Radio says "Clone Error" shortly after "Clone TX". No download bar shows on Chirp -- This used to work with Chirp 0.1.11
Clicking on the Chirp download for the VX5 "Cancel" button won't exit.. gives errors: -- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/cloneprog.py", line 58, in <lambda> cancel_b.connect("clicked", lambda b: cancel()) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/clone.py", line 210, in cancel self.kill(CloneCancelledException) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirp/chirp_common.py", line 1031, in kill raise Exception("Failed to signal thread!") Exception: Failed to signal thread! 000: 00 00 00 00 00 00 00 00 ........
Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/cloneprog.py", line 58, in <lambda> cancel_b.connect("clicked", lambda b: cancel()) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/clone.py", line 210, in cancel self.kill(CloneCancelledException) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirp/chirp_common.py", line 1031, in kill raise Exception("Failed to signal thread!") Exception: Failed to signal thread! Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/cloneprog.py", line 58, in <lambda> cancel_b.connect("clicked", lambda b: cancel()) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/clone.py", line 210, in cancel self.kill(CloneCancelledException) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirp/chirp_common.py", line 1031, in kill raise Exception("Failed to signal thread!") Exception: Failed to signal thread! Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/cloneprog.py", line 58, in <lambda> cancel_b.connect("clicked", lambda b: cancel()) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/clone.py", line 210, in cancel self.kill(CloneCancelledException) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirp/chirp_common.py", line 1031, in kill raise Exception("Failed to signal thread!") Exception: Failed to signal thread! Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/cloneprog.py", line 58, in <lambda> cancel_b.connect("clicked", lambda b: cancel()) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/clone.py", line 210, in cancel self.kill(CloneCancelledException) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirp/chirp_common.py", line 1031, in kill raise Exception("Failed to signal thread!") Exception: Failed to signal thread! Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/cloneprog.py", line 58, in <lambda> cancel_b.connect("clicked", lambda b: cancel()) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/clone.py", line 210, in cancel self.kill(CloneCancelledException) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirp/chirp_common.py", line 1031, in kill raise Exception("Failed to signal thread!") Exception: Failed to signal thread! Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/cloneprog.py", line 58, in <lambda> cancel_b.connect("clicked", lambda b: cancel()) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/clone.py", line 210, in cancel self.kill(CloneCancelledException) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirp/chirp_common.py", line 1031, in kill raise Exception("Failed to signal thread!") Exception: Failed to signal thread! Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/cloneprog.py", line 58, in <lambda> cancel_b.connect("clicked", lambda b: cancel()) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirpui/clone.py", line 210, in cancel self.kill(CloneCancelledException) File "/usr/src/archive/Chirp/chirp-hg-c00282ce90f6/chirp/chirp_common.py", line 1031, in kill raise Exception("Failed to signal thread!") Exception: Failed to signal thread! ^CTraceback (most recent call last): File "./chirpw", line 120, in <module> gtk.main() --
When running Chirp from the command line (not in the background, etc.), hitting Control-C won't exit the program, I only see the following on the command line: -- KeyboardInterrupt
Kenwood TH-F6A -- Downloads all 400 memories but they all show error -- This used to work in Chirp 0.1.11
Kenwood D710 -- Will try later tonight but I need to backup the radio with Kenwood's Windows-only tool first as I don't want to loose all my settings
Mode issues -- No option for WFM (broadcast) in the Chirp mode pulldown - Kenwood THF6A supports this
Usability issues: -- Numeric keypad doesn't seem to work for entering frequencies
In IM'ing with Marco, it seems that Chirp detects (more like guesses) the radio model based upon the saved image file size! This is not going to be reliable. I'd argue that Chirp should either prepend a signature in the .img file or it should create an associated meta file with the same name as the .img file that contains details about the image (radio vendor, model, etc.)
It has been quite reliable thus far and there are automated tests to make sure that no two radios clash in this regard. For radios that have sufficient model information embedded, that information is used instead of file size.
Clicking on the Chirp download for the VX5 "Cancel" button won't exit.. gives errors:
Yeah, this is using a feature in python for signaling another thread that seems to no longer work in newer versions.
Kenwood TH-F6A
Downloads all 400 memories but they all show error -- This used to work in Chirp 0.1.11
Sorry, are you claiming that the addition of the 857 patch broke all of these radios? I'm not sure how that could have happened.
Kenwood D710
Will try later tonight but I need to backup the radio with Kenwood's Windows-only tool first as I don't want to loose all my settings
The Kenwood radios are not clone mode, so you don't have to worry about that.
No option for WFM (broadcast) in the Chirp mode pulldown - Kenwood THF6A supports this
You can file a bug on the website for this and I'll comment there on how you can help resolve this (I don't have an F6A to test with).
Numeric keypad doesn't seem to work for entering frequencies
Chirp doesn't do anything fancy with keybindings, so I expect you have your numeric pad disabled or configured for mouse movement.
Hey Dan,
It has been quite reliable thus far and there are automated tests to make sure that no two radios clash in this regard. For radios that have sufficient model information embedded, that information is used instead of file size.
Is that information saved into the saved .img file itself?
Clicking on the Chirp download for the VX5 "Cancel" button won't exit..
Yeah, this is using a feature in python for signaling another thread that seems to no longer work in newer versions.
Hmmm.. bummer. That's the only real complaint I've heard with Python over the years... it's threading isn't all that hot.
-- Downloads all 400 memories but they all show error -- This used to work in Chirp 0.1.11
Kenwood TH-F6A
Sorry, are you claiming that the addition of the 857 patch broke all of these radios? I'm not sure how that could have happened.
No, that's not what I meant to say. What I did mean is that it seems this current tip of tree that I applied the FT857 patches to seems to have broken the support for my other radios.
Kenwood D710
Will try later tonight but I need to backup the radio with Kenwood's Windows-only tool first as I don't want to loose all my settings
The Kenwood radios are not clone mode, so you don't have to worry about that.
Ok.. fair enough but when I tried with my Kenwood FH-F6A, all the downloaded memories showed the memory text field as "ERROR" and it downloaded all 400 memories as "error"
THF6A supports this
No option for WFM (broadcast) in the Chirp mode pulldown - Kenwood
You can file a bug on the website for this and I'll comment there on how you can help resolve this (I don't have an F6A to test with).
Ok.. It looks like your moving away from Trac and you are now using Redmine. I've signed up for an account and I'll file the bug in a bit.
Numeric keypad doesn't seem to work for entering frequencies
Chirp doesn't do anything fancy with keybindings, so I expect you have your numeric pad disabled or configured for mouse movement.
I'll look at that but I think the numeric keypad works everywhere else.
Anyway... I think at this stage, it would be safe to add the FT857 code into the repository though it would be good to hear what Kurt finds with his FT817.
--David
Is that information saved into the saved .img file itself?
Everything the radio dumps to us is stored in the .img file. If the radio sent us identifying information, then it is, yeah. Run "hexdump -C" on one of the VX-X images in the tests/ directory for an example.
Hmmm.. bummer. That's the only real complaint I've heard with Python over the years... it's threading isn't all that hot.
It's only a problem because I was lazy and didn't implement something better in the read loops within the drivers and depended on this working. IMHO, Python's threading support is about as good as most. You're probably thinking of the fact that the interpreter isn't multi-threaded, nor reentrant, which really isn't related to this problem.
No, that's not what I meant to say. What I did mean is that it seems this current tip of tree that I applied the FT857 patches to seems to have broken the support for my other radios.
Hmm, well, I've not heard such reports. It would be very helpful if you could do a little bisection to determine where you think things broke. If you clone the actual source tree, then you can move through the changesets pretty easily in a single directory without downloading a bunch of tarballs.
Ok.. fair enough but when I tried with my Kenwood FH-F6A, all the downloaded memories showed the memory text field as "ERROR" and it downloaded all 400 memories as "error"
Understand, but CHIRP won't push error'd memories back to the radio. It can't. Kenwood radios are the pinnacle of obsessive verification. If you send a memory (they're sent to the radio one at a time in text format) that doesn't meet spec, it will outright reject it.
Please grab the console output and post it here so I can see. Hopefully that will provide some insight into what's going on. I recently made some fixes for the TH-F7A, which could have broken the F6, I suppose, but I usually hear about those fairly quickly.
I'll look at that but I think the numeric keypad works everywhere else.
Okay, well, the default on my 11.10 machine is to use the numeric pad for mouse keys. With that disabled, the numeric pad works fine in chirp for me.
Anyway... I think at this stage, it would be safe to add the FT857 code into the repository though it would be good to hear what Kurt finds with his FT817.
Yeah, I just talked to him and he's going to try it in the next day or so. I'll hang on for that.
Upon restart, all memories and FT857 system settings were lost --> Sure would be nice if the program could also handle the higher level menu settings at lease just as a binary blob and allow to be able to restore or not-restore that when uploading back to the radio
The radio self-destructs after an unsuccessful clone. The entire memory contents are transferred, which means once the clone process is fixed, you won't see a reset of the other settings (of course).
In the Radio dialog, it's not remembering the last serial port I used. Specifically, I have my port named via UDEV as /dev/ft857_prog
It should/will after a successful clone and a graceful exit.
Chirp About --> Credits doesn't show Marco
Yes, we need to fix that, and for Rick as well for the VX-3 driver.
Hi Dan
Note that it's very unconventional to send a merge changeset like this to a maintainer in email. Since my tree already has those changes, it won't apply for me. This is because you're committing changes directly to your tree and pulling from the repository, which is fine but has this other little snag.
Ops ... I'm sorry ...
Anyway, I'll fix and apply these patches as they are this time. Are we confident that the 857 driver is ready? I haven't seen a report from anyone else (David?) that they have been successful and I don't have an 857 to test with.
I think that we need to wait someone (other then me) to test it before applying the patches to the repository, just to be sure that is not my radio the only one that works ;) I'm sorry but I'm a little sick due to a flu so there will be a little delay. I hope to be able to work on missing things in a day or two.
73 de IZ3GME Marco
I think that we need to wait someone (other then me) to test it before applying the patches to the repository, just to be sure that is not my radio the only one that works ;)
Sounds good. Hopefully we'll hear from David soon.
I'm sorry but I'm a little sick due to a flu so there will be a little delay. I hope to be able to work on missing things in a day or two.
Yikes, sorry to hear that.. Go to bed!
Hey Dan, Marco,
Ok, I'll try out the patches tonight assuming that I can get that RT Systems cable working under the FTDI driver:
Dan: Two questions:
1. To test the RT cable, do you know of a simple text string to send to the 857 to see if it's properly receiving and I get a known response back?
2. I'm assuming I can download the newest nightly snapshot and apply Marco's emailed patches (except his "merge" patch) or do I need to use a different version of Chirp?
--David
I think that we need to wait someone (other then me) to test it before applying the patches to the repository, just to be sure that is not my radio the only one that works ;)
Sounds good. Hopefully we'll hear from David soon.
I'm sorry but I'm a little sick due to a flu so there will be a little delay. I hope to be able to work on missing things in a day or two.
Yikes, sorry to hear that.. Go to bed!
I tried the FT857 patches again with today's tip of tree and I still get a failure:
----------------------------------------------- 1. Had to edit all patches to remove the a/ and b/ from the file paths
----------------------------------------------- 2. common patch worked ok per email "[chirp_devel] [PATCH 1 of 4] Add "valid_cross_modes" to RadioFeatures"
patch -p0 < chirp-common.patch patching file chirp/chirp_common.py Hunk #1 succeeded at 546 (offset -2 lines). Hunk #2 succeeded at 646 (offset -2 lines). Hunk #3 succeeded at 765 (offset -2 lines). patching file chirpui/memedit.py
----------------------------------------------- 3. FT857 patch didn't work per email "[chirp_devel] [PATCH 2 of 4] Set valid_cross_modes as needed" I assume we have to have the file first but it doesn't apply cleanly either way
# patch -p0 < ft857.patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- chirp/ft857.py Sat Jan 21 09:59:33 2012 +0100 |+++ chirp/ft857.py Sat Jan 21 10:00:34 2012 +0100 -------------------------- File to patch: ^C
cp chirp/ft817.py chirp/ft857.py # patch -p0 < ft857.patch patching file chirp/ft857.py Hunk #1 FAILED at 109. 1 out of 1 hunk FAILED -- saving rejects to file chirp/ft857.py.rej
---------------------------------------------- 4. Patching runtests ok per email "[chirp_devel] [PATCH 4 of 4] Use valid_cross_modes during test" though it doesn't talk about HUNKS
patch -p0 < run-tests.patch patching file tests/run_tests
---------------------------------------------- 5. I did NOT apply the "merge" patch via email "[chirp_devel] [PATCH 3 of 4] merge" from the recommendation of Dan
What am I missing?
--David
David Ranch wrote:
Hey Dan, Marco,
Ok, I'll try out the patches tonight assuming that I can get that RT Systems cable working under the FTDI driver:
Dan: Two questions:
1. To test the RT cable, do you know of a simple text string tosend to the 857 to see if it's properly receiving and I get a known response back?
2. I'm assuming I can download the newest nightly snapshot andapply Marco's emailed patches (except his "merge" patch) or do I need to use a different version of Chirp?
--David
- Had to edit all patches to remove the a/ and b/ from the file paths
Apply with "patch -p1".
- FT857 patch didn't work per email "[chirp_devel] [PATCH 2 of 4] Set
valid_cross_modes as needed" I assume we have to have the file first but it doesn't apply cleanly either way
You need to apply his original patch (FT857 pre alpha) first, which adds the ft857 file (note in the patch 0/4).
Hey Dan, Marco,
- Had to edit all patches to remove the a/ and b/ from the file paths
Apply with "patch -p1".
So the -p1 will allow for fuzzy matches on the patch's paths?
- FT857 patch didn't work per email "[chirp_devel] [PATCH 2 of 4] Set
valid_cross_modes as needed" I assume we have to have the file first but it doesn't apply cleanly either way
You need to apply his original patch (FT857 pre alpha) first, which adds the ft857 file (note in the patch 0/4).
Ah... now I see what happened. In Thunderbird, I see that original "ft857 pre alpha" email as coming from:
Marco Filippi IZ3GME iz3gme.marco@gmail.com
Yet the other patches sent from Macro with the subject of "[PATCH x of 4] in the subject line shows as being from:
IZ3GME Marco iz3gme.marco@gmail.com
I have no idea why Thunderbird thinks these are different email addresses but that's why I missed that first patch as I was sorting on Sender for that first email address! Lovely. Anyway... I'll give this a go later today.
--David
- To test the RT cable, do you know of a simple text string to send to
the 857 to see if it's properly receiving and I get a known response back?
Nope, and it doesn't look like the image has a typical yaesu ID string in the front, which is how I tell people to test the VX radios.
- I'm assuming I can download the newest nightly snapshot and apply
Marco's emailed patches (except his "merge" patch) or do I need to use a different version of Chirp?
Yep, that should be fine.
participants (4)
-
Dan Smith -
David Ranch -
IZ3GME Marco -
Marco IZ3GME