Yaesu's serial protocol.

iz3kxw

New Member
Good afternoon,
i introduce myself, my name is Andrea and i’m writing from Italy. I’m a newbie with the Picaxe and I need some information regarding my project.
By a Picaxe 08M2 i have to control a Yaesu FT847 rigs with own serial protocol. Each instruction to send the radio consist of 5 bytes, the pause between each byte must be 200mS, the format of the single byte is:

- start bit - bit0 – bit1 – bit2 – bit3 – bit4 – bit5 – bit6 – bit7 – stop bit – stop bit – Total are 11 bits

As you see this protocol is different from the protocol of Picaxe that is - 8bit data – no parity – stop bit –

My question is: how can I write the right code in order to meet the requirements Yaesu’s protocol ??
I apologize if the topic has already been treated, but have not found anything like.

Thank you for the help.
Andrea P. IZ3KXW.
 

nick12ab

Senior Member
Welcome to the PICAXE Forum.

Isn't a stop bit really just the same as idle? The code execution delay introduced by the PICAXE interpreter will be enough to lengthen the stop bit for you. All you need to do is use a separate serout command for each byte and you can use the pause command for the 200ms delay. If a microsecond delay is required, use the pauseus command.

Example:
Code:
    serout 0,N2400,(b1)
    pause 200
    serout 0,N2400,(b2)
    pause 200
    serout 0,N2400,(b3)
    pause 200
    serout 0,N2400,(b4)
    pause 200
    serout 0,N2400,(b5)
 

iz3kxw

New Member
Thank you for the quick response,
is much simpler than i thougt, tonight i try to write down the code and test it with the radio.
Ciao. Andrea P.
 

hippy

Technical Support
Staff member
Another technique is to use the scratchpad ('ptr') or the RAM ('bptr'), build up the data to send, and then send it ...

Code:
  ptr = 0
  @ptrInc = "H"
  @ptrInc = "e"
  @ptrInc = "l"
  @ptrInc = "l"
  @ptrInc = "o"
  Gosub Send
  End

Send:
  b0 = ptr
  ptr = 0
  Do While ptr <> b0
    SerOut .... ( @ptrInc )
    Pause 200
  Loop
  Return
 

Goeytex

Senior Member
I looked at the manual for this very nice Transceiver and found this....

All commands sent from the computer to the transceiver consist of five-byte blocks,
with up to 200 ms between each byte. The last byte in each block is the instruction
opcode, while the first four bytes of each block are arguments (either parameters
for that instruction, or dummy values required to pad the block out to five bytes).
Each byte consists of 1 start bit, 8 data bits, no parity bit, and two stop bits.
This tells us that that there can be "up to" 200ms between bytes. This is a maximum value and not a minimum requirement.
Therefore you will probably will not need to add any delay between bytes using Picaxe serout... since while serout may be specified
as 8,N,1 the output is actually closer 8,N,2 or even 8,N,3. (The latest firmware adds some extra space between bytes.)

This means that your code can most likely be simplified to something like:

Code:
serout c.2, T9600_4, (b0,b1,b2,b3,b4)   [COLOR="#008000"] '5 bytes[/COLOR]
 

iz3kxw

New Member
Hello guys,
here i am again with my project.
With a picaxe 14m2 I can successfully control the radio with serout,
this is the code: serout C.4,T4800_4, (0X00,0X00,0X00,0X00,0X00) switch on the RTX
serout C.4,T4800_4, (0X00,0X00,0X00,0X00,0X80) switch off the RTX etc.etc.
but now I have another problem, when I ask the RTX to give me back the frequency with the command
serout C.4,T4800_4, (0X00,0X00,0X00,0X00,0X03) and then the command serin B.1,T4800_4, b0,b1,b2,b3,b4 (the RTX give back 5 bytes)
I receive only strange numbers, not consistent with the real frequency, ex. b0=253 b1=254 b2=254 b3=254 b4=0.
I think that is because the protocol of the RTX is &#8220;1bit start,8bit data, no bit parity, 2bit stop&#8221; and the picaxe can&#8217;t read it.
I already tried with others commands, serrxd and hserin but nothing, same result.
May be somebody has had the same problem and can help me?
I thank you for the help.
Andrea. Iz3kxw
 

hippy

Technical Support
Staff member
I receive only strange numbers, not consistent with the real frequency, ex. b0=253 b1=254 b2=254 b3=254 b4=0.
I think that is because the protocol of the RTX is &#8220;1bit start,8bit data, no bit parity, 2bit stop&#8221; and the picaxe can&#8217;t read it.
The PICAXE serial format should be compatible with what the rig sends out. It could be the data is returned too soon for SERIN to be ready. The 08M2 doesn't have high-speed receive into scratchpad so HSERIN might not help but running at a faster speed might.

Do you have a link to a manual or datasheet detailing the protocol ?

What you current code is might also help.
 

iz3kxw

New Member
The PICAXE serial format should be compatible with what the rig sends out. It could be the data is returned too soon for SERIN to be ready. The 08M2 doesn't have high-speed receive into scratchpad so HSERIN might not help but running at a faster speed might.

Do you have a link to a manual or datasheet detailing the protocol ?

What you current code is might also help.
I tried with HSERIN but the picaxe doesn't receive nothing, with SERIN i changed also the freq to 8, 16 and 30 mhz but nothing changed.

try to read at this : http://www.ka7oei.com/ft817_meow.html i hope it help to understand something.

ciao Andrea.
 

g6ejd

Senior Member
Hi Andrea. Iz3kxw

I have successfully controlled my FT897, which uses the same Yaesu protocol and like has been ssuggested added a delay of 104uS (in my case as I use 9600 baud) and this simulates the required extra stop bit. In PICAXE receive mode it works fine as the PICAXE only needs 1-stop bit, but gets two which is in effect a pause during receive.

I suspect you have a connection/polarity problem on receive, are you using RS-232 (inverted data) or TTL/RS423. You can test your communications by changing freqency or band as the FT will output the change of frequency data and you shoudl be able to display that in debug mode or on a LCD display.
 

iz3kxw

New Member
What is the real frequency?

What are you expecting?
the real rtx frequency was 10.000.000 hz, (10Mhz) and the 5 bytes should contain (0x01, 0x00, 0x00, 0x00, 0x00) instead of the received (0xFD, 0XFE, 0XFE, 0XFE, 0X00).

ciao Andrea
 

hippy

Technical Support
Staff member
I would agree with g6ejd that it's likely polarity or baud rate, but polarity would normally be the same for send and receive, and it seems sending commands does work.

Perhaps start with sending commands which return a one byte response before moving on to commands which return multiple bytes.
 

nick12ab

Senior Member
the real rtx frequency was 10.000.000 hz, (10Mhz) and the 5 bytes should contain (0x01, 0x00, 0x00, 0x00, 0x00) instead of the received (0xFD, 0XFE, 0XFE, 0XFE, 0X00).
Perhaps you have to subtract the first four bytes from 254.
 

iz3kxw

New Member
Hi Andrea. Iz3kxw



I suspect you have a connection/polarity problem on receive, are you using RS-232 (inverted data) or TTL/RS423.
this is my circuit 14M2-ft847.png
ft847 is equipped with a 232 converter, so i inverted the signals by 2 optocoupler, i think my connection polarity is working well because the rig receive the command by 14M2. Is the 14M2 that don't receive the right data from the rig. I would like to try to analyze the signal from the rig with a scope and see if as Hippy said a first byte is send before the other five.

ciao Andrea.
 

Goeytex

Senior Member
The Operator manual can be found ====> HERE Page 90

The manual does not give the timing between data received and data sent unless I missed it. The manual doe not even address receiving data in this manner.
 
Last edited:

hippy

Technical Support
Staff member
Could be the receive polarity is different to the transmit polarity and that's the first thing I'd try. The $FD / $FE values look symptomatic of that to me but a little inexplicable as to why or how that could be until seeing the hardware interface. It may not be that, but an easy enough change to test.
 

iz3kxw

New Member
Could be the receive polarity is different to the transmit polarity and that's the first thing I'd try. $FD / $FE values look symptomatic of that to me but a little inexplicable as to why or how that could be until seeing the hardware interface. It may not be that, but an easy enough change to test.
Hippy, i tried to invert physically the receive polarity but did not work, only if i invert the polarity at baud rate like N4800_4 i can receive the 5 bytes but with the same value.
I thought the same thing, the value received seem to be inverted or something like this.
I try to put a delay of 208uS before each SERIN and see what happen. (208uS is the lengh of a singol bit at baud 4800).

One more thing, anybody know if there is a software for win that analyze the serial signal incoming from the rig?

Ciao Andrea.
 

Technical

Technical Support
Staff member
Are your opto-isolators performing an unwanted inversion? Is LED1 normally (idle) on - pulsing low, or idle off - pulsing high?
 

iz3kxw

New Member
Are your opto-isolators performing an unwanted inversion? Is LED1 normally (idle) on - pulsing low, or idle off - pulsing high?
When there is not data the Led1 is always on, so pin C.4 is pulled to zero, the same think is for Led2 and the pin2 of the DB9 plug is pulled to -10volt.
So they are pulsing low.
 

iz3kxw

New Member
When there is not data the Led1 is always on, so pin C.4 is pulled to zero, the same think is for Led2 and the pin2 of the DB9 plug is pulled to -10volt.
So they are pulsing low.
I made a small mods to the rig, i connected +10V and -10V to the pin 9 and 1 of the DB9 plug in order to galvanically separate the picaxe from the rig.
 

Technical

Technical Support
Staff member
When there is not data the Led1 is always on, so pin C.4 is pulled to zero, the same think is for Led2 and the pin2 of the DB9 plug is pulled to -10volt.
So they are pulsing low.
That explains your different polarities. The PICAXE will need to use T4800 (idle high, pulse low) to transmit and N4800 (idle low, pulse high) to receive. Hence the receive polarity is in turn inverted from what you expect, hence the inverted byte values.
 
Last edited:

g6ejd

Senior Member
As I expected and Hippy has already confirmed (IZ3KXW thanks for the circuit diagram), the PIN-3 circuit is non-inverting and PIN-2 circuit is inverting, so if you follow Hippy's suggestion above, that will solve your problem.
 

iz3kxw

New Member
As I expected and Hippy has already confirmed (IZ3KXW thanks for the circuit diagram), the PIN-3 circuit is non-inverting and PIN-2 circuit is inverting, so if you follow Hippy's suggestion above, that will solve your problem.
setfreq m32

main:

serout C.4,T4800_32,(0x00,0x00,0x00,0x00,0x00) ;switch on CAT
pause 100
serout C.4,T4800_32 (0x00,0x00,0x00,0x00,0x03) ;read freq. rig
serin B.1,N4800_32,b0,b1,b2,b3 ;receive freq.rig
pause 100
let w2=b0+b1+b2+b3 ;add.value for later comparison
debug
end
14M2-ft847.png


Hi, tonight i solved my issues, as you wrote it was my mistake, i confused T and N command, if you see now i modified the hardware
(pin3 and pin5 of DB9 plug) and also the code, but, work well only at 32Mhz, if i set a lower freq. sometimes the values received are incorrect.
One more thing, if i do the sum of b0,b1,b2,b3 without a small pause the values received by serin are incorrect and sometimes slow to get,
seems that 14M2 not have enought time to process the data.
Anyway now is working well and i must thank you for the great help.

ciao Andrea, iz3kxw
 

hippy

Technical Support
Staff member
One more thing, if i do the sum of b0,b1,b2,b3 without a small pause the values received by serin are incorrect and sometimes slow to get, seems that 14M2 not have enought time to process the data.
That almost certainly is not the case and a PAUSE between SERIN and LET will never be necessary.

It's probably that the code runs so quickly that without the PAUSE it will have executed the DEBUG and finished before the Programming Editor has even started looking for DEBUG messages.
 
Top