sergev / baoclone Goto Github PK

What steps will reproduce the problem?
1. download configuration from the transceiver to device.conf file (using 
'baocode <Serial Port>' command)
2. Open the program generated device.conf  and find Power  value for Mid power. 
3. The value is "Med", which is incorrect.
4. Try to upload just imported configuration file without any changes back to 
the transceiver (using baocode -c <Serial Port>  device.conf command)
5. The program throws error: Bad power level. Invalid line: '    1   MAIN    
146.4600 +0          -    123.0   Med   Wide       +    -'


What is the expected output? What do you see instead?
the expected value for Mid power  is "Mid"

What version of the product are you using? On what operating system?
baoclone version 1.3 for Mac 10.9 

Please provide any additional information below.
after changing the  power level code from "Med" to "Mid" the file is uploaded OK

What steps will reproduce the problem?
1. Usin baoclone 1.3 on FT-60R
2.
3.

What is the expected output? What do you see instead?
Expected is the correct frequencies and PL tones.  I see different for random 
channels.  i.e.  
Frequency Should be        Frequency is written
145.510                    145.500
145.825                    145.820
448.340                    448.3375

What version of the product are you using? On what operating system?
1.3 on Ubuntu 13.10 on a Yaesu Ft-60R

Please provide any additional information below.
Odd offsets are changed as well on random channels.

Thank you

What steps will reproduce the problem?
1.In VFO mode, VFO A; set offset (menu 26) to any nymber, exaple 00.600
2.In SFT-D (menu 25) set it to - (negative)
3.Download the device configuration.
4.Look at device.conf at VFO setup/data
5.The ofsset value is always + and multiplied by 10. Example:
6.THe VFO B, I set offset to +1.600

 A  VHF  136.0250 +6          -       -    2.5  High  Wide   -  
 B  UHF  470.6250 +16         -       -    2.5  High  Wide   -  


What is the expected output? What do you see instead?
The expected output is

 A  VHF  136.0250 -0.600          -       -    2.5  High  Wide   -  
 B  UHF  470.6250 +1.600         -       -    2.5  High  Wide   -  

 I have no problem with Channel Mode setup.

What version of the product are you using? On what operating system?
GNU/Linux Slacware64, and using baoclone version git-current  d2c4a4b 2013-11-01

Please provide any additional information below.
I am using Baofeng A52, which has similar internal with  GT-3 . Firmware 
version is BFS311. 

I attached the device.img for your reference.

I am very happy with baoclone, I made compiled my country's repeaters which are 
102, and using sed and awk, I can create a table which baoclone can parse in 
juse less than a second. :) 


BTW, please remove -m32 for CC parameters in Makefile, so, it can be compiled 
with 64 bit gcc in 64bit GNU/Linux.
--- Makefile.orig       2014-03-31 10:59:54.660769094 +0800
+++ Makefile    2014-03-31 10:59:54.661769094 +0800
@@ -1,4 +1,4 @@
-CC             = gcc -m32
+CC             = gcc 

 VERSION         = 1.4
 CFLAGS         = -g -O -Wall -Werror -DVERSION='"$(VERSION)"'


Thank you.

What steps will reproduce the problem?

1. Clone the config of a Baofeng UV-5R which has no channel names (as would be 
true if the radio has only previously been programmed from the faceplate), 
generating a device.conf file.
2. Attempt to write that device.conf file (i.e. NOT the .img) back to the radio 
using the -c flag.

What is the expected output? What do you see instead?

The expected result is that the radio be reprogrammed with the contents of the 
generated config file, which should put the radio in its original state (since 
the config was generated off the radio's current state). 

The actual result is that the baoclone utility claims the lines in the "Table 
of programmed channels" section are invalid configuration lines. For example:

    $ baoclone -c /dev/tty.PL2303-00001004 device.conf 
    Connect to /dev/tty.PL2303-00001004.
    Detected Baofeng UV-5R.
    Read device: ################################################## done.
    Radio: Baofeng UV-5R
    Firmware: Ver  BFB297
    Serial: [removed]
    Write image to file 'backup.img'. 
    Read configuration from file 'device.conf'.
    Invalid line: '    1           144.3900  0          -       -    High  Wide   +    -   -     -'

This issue appears to be that I've only ever programmed my radio from the 
faceplate, and thus my memory channels do not have alphanumeric names. The 
generated baoclone .conf file therefore has no text in the second field for 
each memory location. 

When uv-5r.c attempts to parse this generated config file in parse_channel() 
using `sscanf(line, "%s %s ...` on line 1174, it presumably misses the missing 
name field, thus retrieving 11 fields rather than 12. This is my supposition; I 
have not confirmed with a debugger or a careful analysis of the code. 

My workaround is to duplicate the channel number field for use as the channel 
name for channels which do not have specific alphanumeric names assigned. 

I would suggest one or more of the following fixes be implemented:

- That the baoclone config file generator implement the channel-number-as-name 
workaround; 
- or that a more sophisticated parser which can handle missing fields be used 
in parse_channel();
- or that the config syntax be modified to allow for explicit configuration of 
empty field – either with an "empty" symbol (e.g. "-"), or by switching to a 
non-whitespace delimiter, as in a comma separated value (CSV) file. 

However, I am not familiar enough with the code base to make a firm 
recommendation. 

What version of the product are you using? On what operating system?

I'm using git head at 4a399db2b0a39bbf7de7b0fa9bd55280521c7f96 (i.e. baoclone 
v1.2), compiled on Mac OS X 10.6.7 Slow Leopard. 

Please provide any additional information below.

I'm attempting to clone/program a Baofeng UV-5RA (late 2012) radio which has 
never previously been programmed from a computer. The radio's memory channels 
thus do not have alphanumeric name labels.

I've got a small patch to add support for disabling transmit on the UV-5R 
(tested on the UV-5RA) on a channel-by-channel basis. 

I've added support for specifying "-" in the TX offset field of a config file 
channel line to mean "disable transmit." 

If the parser sees a "-," the TX offset will be set to the max frequency, which 
will make the TX frequency passed to setup_channel() greater than the max 
frequency. 

If setup_channel() gets an out of valid range TX frequency, it will set the 
frequency in the radio to 0xffffffff, which appears to be the Baofeng's code to 
disable transmit on the channel. See http://chirp.danplanet.com/issues/211 for 
a discussion of this. I've confirmed that setting this does disable TX on my 
UV-5RA. 

On the config generation side, if the radio or .img contains a frequency of 
1666666650 Hz, equivalent to 0xffffffff, the config printer will output "-" 
instead of a computed offset. 

Here's the comparison on Github of my branch with your master: 
https://github.com/casebeer/baoclone/compare/disabled-transmit

The branch with the change is "disabled-transmit:" 
https://github.com/casebeer/baoclone/tree/disabled-transmit

Please let me know if there's anything you'd like me to change about this, or 
that you'd like clarification on. 

Thanks, 

Chris

-    static const unsigned char UVB5_MODEL[] = "PROGRAM";
+   static const unsigned char UVB5_MODEL[] = "\2PROGRAM";

        serial.write(b"\x02")
        time.sleep(0.1)
        serial.write(b"PROGRAM")
        ack = serial.read(1)