Hi Tom,
I don't have the radio any more in my hands, it was borrowed for a short time frame and the friend that give me the radio is not there anymore to help me (it's retired from working now). That's the main reason I have halted the development of it, the ball is on your park now if you want to keep it rolling.
The life has strange turns, you kind of started it a time ago, and now you are invited to finish it. ;-)
Please by my guest.
The changes you made seems fine to me.
73.
El 08/06/16 a las 22:35, Tom Hayward via chirp_devel escribió:
On Wed, Feb 24, 2016 at 2:51 PM, Pavel Milanes (CO7WT) co7wt@frcuba.co.cu wrote:
Hi Tom,
I think I nailed, attached is the first beta driver for the Kenwood TK-790.
Please try it if you have the time, any comments will be appreciated, also if you encounter any error the debug.log will be very useful (zip it please)
Cheers, Pavel CO7WT
Hi Pavel,
I've been working through the TK-790 driver you sent me and made a number of changes. Downloads are now working for me fast and consistently.
I'm not sure if you encountered this problem, but often when I would put the radio into PROGRAM mode, I would not immediately see an ack. This would abort the download. It seems this radio likes to send serial data for every possible event, so often when I would go to read the ack there would be 100+ bytes in the input buffer (and this is after clearing the buffer immediately before issuing the PROGRAM command!). Consistently, however, I would see the ack at the end of all this garbage. I noticed that the information frames (the "garbage") all ended in 0xFF, so I added a way to chew through them:
_raw_send(radio, "PROGRAM") ack = _raw_recv(radio, 1024) while ack: if ack[0] == ACK_CMD: break ack = ack[ack.index('\xff')+1:] else: radio.pipe.write("E") raise errors.RadioError("Radio didn't acknowledge program mode.")This will look for the ack after the garbage/information frames, but never inside them! One issue down...
The other problem I encountered was very slow downloads. In many cases the code was requesting more bytes than the radio was sending, so we had to wait for the timeout to expire. I refactored _recvl() and _recvh() such that they now only request as many bytes as needed. This makes downloads very fast! This negates the need for short timeouts and sleeps, so I removed those.
I haven't tested upload.
I noticed the tests crash on the bank code, but haven't looked into it.
Attached is my updated tk790.py. Disclaimer for those on the sidelines: it's very much a work in progress!
Tom KD7LXL
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers