Not sure but the trace of the program that works opens, closes and re-opens the connection before sending. I have tried different baud rates, stop bits, and byte sizes but the radio does not seem to respond to the commands as it does in the serial tracing. 73, Alan - W6ARH

-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com [mailto:chirp_devel-bounces@intrepid.danplanet.com] On Behalf Of Dan Smith Sent: Thursday, November 01, 2012 6:38 PM To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Quansheng Programming

I have yet to be successful opening a dialog with the radio. I am almost at the point of giving up. The last thing for me to try is to close the serial port and re-open it. Rather than rooting through the code I thought I would ask if this can be accomplished and how?

Why do you think that will help? What sort of troubles are you running into?

The serial port is opened right before it calls your driver:

ser = serial.Serial(port=settings.port, baudrate=rclass.BAUD_RATE, rtscts=rclass.HARDWARE_FLOW, timeout=0.25)

So, you can do that again in your driver for debugging if you think it will help. However, I'd encourage you to tell us what you've tried, what you've learned, and ask for help. There's a lot of collective knowledge about reverse engineering radios here :)

-- Dan Smith www.danplanet.com KK7DS

Here is the file from a read of the radio. Its pretty straightforward to interpret. 73, Alan - W6ARH

-----Original Message----- From: shawn [mailto:shawn@busymarvin.net] Sent: Friday, November 02, 2012 12:23 AM To: chirp_devel@intrepid.danplanet.com Cc: The Silver Fox Subject: Re: [chirp_devel] Quansheng Programming

Have you been able to successfully program the radio with the factory software?

If so, can you get a capture of that?

On 11/1/2012 7:32 PM, The Silver Fox wrote:

Not sure but the trace of the program that works opens, closes and re-opens the connection before sending. I have tried different baud rates, stop bits, and byte sizes but the radio does not seem to respond to the commands as it does in the serial tracing. 73, Alan - W6ARH

-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com [mailto:chirp_devel-bounces@intrepid.danplanet.com] On Behalf Of Dan Smith Sent: Thursday, November 01, 2012 6:38 PM To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Quansheng Programming

...

I have yet to be successful opening a dialog with the radio. I am almost at the point of giving up. The last thing for me to try is to close the serial port and re-open it. Rather than rooting through the code I thought I would ask if this can be accomplished and how?

Why do you think that will help? What sort of troubles are you running

into?

The serial port is opened right before it calls your driver:

ser = serial.Serial(port=settings.port, baudrate=rclass.BAUD_RATE, rtscts=rclass.HARDWARE_FLOW, timeout=0.25)

So, you can do that again in your driver for debugging if you think it will help. However, I'd encourage you to tell us what you've tried, what you've learned, and ask for help. There's a lot of collective knowledge about reverse engineering radios here :)

-- Dan Smith www.danplanet.com KK7DS

---

chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel

-- --Shawn --KF7WXG

If it would help, I have the binary format of the Qansheng .dat file almost completely mapped out. It looks a lot like a "c" structure layed out in memory. I have a standalone program that can read & write all of the fields from/to the binary/human readable forms.

If that would be of help, just let me know.

Jeff

On Fri, Nov 2, 2012 at 12:08 PM, Dan Smith dsmith@danplanet.com wrote:

...

Here is the file from a read of the radio. Its pretty straightforward to interpret.

Looks identical (in structure) to all the other chinese radios, so this should be easy. We can't help you without seeing your code.

-- Dan Smith www.danplanet.com KK7DS

---

chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel

Here is the current code. None of it has been exercised or supported since I can't get past the initial detection. 73, Alan - W6ARH

On Fri, Nov 2, 2012 at 12:08 PM, Dan Smith dsmith@danplanet.com wrote:

...

Here is the file from a read of the radio. Its pretty straightforward to interpret.

Looks identical (in structure) to all the other chinese radios, so this should be easy. We can't help you without seeing your code.

-- Dan Smith www.danplanet.com KK7DS

---

chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel

Just another guess at something to try. I do get answers from the radio at certain port settings but nothing that matches what I expect. I tried big endian, little endian, swapped bytes, and got nothing intelligible. I used gtkterm and got similar junk. The responses do not make sense. The only thing I noticed is that under Linux the radio blinks its display on chirp startup whether or not the radio is on. It does not do that under windows.

Thanks for the advice. Alan

-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com [mailto:chirp_devel-bounces@intrepid.danplanet.com] On Behalf Of Dan Smith Sent: Friday, November 02, 2012 1:36 PM To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Quansheng Programming

# Copyright 2011 Dan Smith dsmith@danplanet.com

This isn't your problem, but be sure to change this :)

def _identify(self):
    """Do the Quansheng identification dance"""
    for _i in range(0, 5):
   print "SENT:\n%s" % util.hexprint(self._querymodel)
        self.pipe.write(self._querymodel + "\r")

This isn't replicating what your trace shows. Why are you sending an extra carriage return?

        resp = self.pipe.read(9)
        if len(resp) != 9:
            print "Got:\n%s" % util.hexprint(resp)
            print "Retrying identification..."

Presumably you get nothing back, is that right?

-- Dan Smith www.danplanet.com KK7DS

One step forward and two steps back. I got the radio to correctly respond a couple of times but I shut it down to change the battery in the radio. After changing the battery, no correct responses can be heard. So, I tried a couple of variations: Radio off when I start chirp, restarting chirp with the radio on, re-trying get radio download multiple times. Still no joy. So it is back to trying all the options on the serial port. Since the radio seems to be sensitive to speed of response from the program and because the factory program opens and closes the serial port multiple times before writing to the radio, I assume that, while I can't tell what it is doing, I assume it is setting serial parameters different from default. I did try hardware flow control with no improvement. I am offering this dialog only to let folks know that I am still working it but haven't yet succeeded. 73, Alan - W6ARH

So, now I am reverting back to stage one. Since the radio does not act reliably as with Windows, I assume that the serial settings are not a match.

If the serial parameters aren't right, you should get much less than 75% reliability. If parity needs to be enabled, and isn't, you'd not likely be able to get enough sequential bytes honored by the radio to do anything.

Secondly, the Windows program closes and re-opens the serial port before communicating with the radio. I am assuming that it is setting non-default parameters on the serial port. My current plan of diagnosis is to try various settings to see if there is a problem there.

Every piece of OEM Windows software I can recall looking at behaves this way. I assume it's some quirk of the API.

Remember that the radios really only communicate with three wires, which means none of the hardware flow control settings have any effect, which rules out a bunch of things.

Unfortunately, I am stuck trying to set the parity. All other parameters seem to be accepted except that one.

There is an example of this in the ft2800 driver, but I *seriously* doubt that is your problem.

Any chance you need to enable DTR or something to power your level converter in the cable? I forget what type you're using...

Still sounds like timing stuff to me, FWIW.

Not sure but the trace of the program that works opens, closes and re-opens the connection before sending. I have tried different baud rates, stop bits, and byte sizes but the radio does not seem to respond to the commands as it does in the serial tracing.

Windows programs seem to that incessantly. I'm not familiar with the platform, but I expect it's some quirk of their API.

Please show us the traces and the code you have for replicating them and we'll have a look!