Need help with Zhen Hua

[Eric Brouwer]

The Zhen Hua protocol is as follow:

19200 Buad, 1 start bit, 8 data bits, 1 stop bit

Synch bit: normally &hEF, but do vary between different types
Data sent as follow:
Channel 1 - Throttle
Channel 2 - Elevator
Channel 3 - Ailerons
Channel 4 - Rudder
All the bits are send in reverse order, so they have to be swapped to get the correct data. That is, bit 7 must become bit 0, bit 6 must become bit 1 etc...

Channel data will always be lower than synch byte.

Cenario 1
On some tx, the data is send in a continuous stream (Synch, Ch1, Ch2, Ch3, Ch4) with about 1.4ms spacing between bytes. 1.4ms delay between Ch4 and next Synck byte. In this case, there is enough time to transmit the decoded data between the received bytes of data.
Decoding:
Read the serial data using software routines
if synch byte found
transmit &hFF
else
swap bits around (channel data)
transmit data
endif

Cenario 2
There is also some that send Synch, Ch1, Ch2, Ch3, Ch4 with about 0.9ms between bytes, then followed by a delay to make up the normal 22ms between Ch4 and the next Synch byte. In this case, there is not enough time to transmit the decoded data between received bytes. One now needs to save the data, and transmit it after the 4th channel was read.
Decoding:
Read the serial data using software routines
if synch byte found
channel counter = 0
else
channel counter = channel counter +1
swap bits around (channel data)
save each channel data
if Channel counter = 4, transmitt &hFF, and 4 saved values
endif

As the output circuit and synch byte was found different between these transmitters, it makes it difficult to get the interface correct on the different types of tx. What might work for 1, might not work for another.

Hope this will help

[phildc]

Thks Eric, will have a look and come back.
Phil.

[phildc]

What is the lowest synch byte that was reported?
Must be some limit as the synch must be higher than data. (or 'coded' data ?)
Phil.

[ShellDude]

I have only ever seen 239 at 19.2.

The results at 9600 baud are quite different... I'm not sure if this is a mismatch of the character set or intentional.

I almost wrote an intercept routine to translate this stuff, then decided I'd just spend $35 for a PIC that has the base encoding FMS expects.

Too bad the ppjoy guy bailed. His source would've made this simple.. heck, the source to FMS would've made it a breeze too.

To the FMS Author(s): Do you have any plans on making your PIC routines more extensible? Seems to me that given a little bit of creativity you could tuck away the various encoding schemes within a lookup table, ideally externalized in a file given the users needs.

Not sure of an easy way to handle the handshake differences. Either way, this transmitter isn't worth the time and trouble.

Thanks for all the info guys. Much appreciated,

Shell

[ShellDude]

I should also add now that I'm seeing some activity on the other interface forums.

The radio we diagnosed above is the "older" version that Walkera packages with their #4 Dragonfly fixed pitch helicopter -- its complete trash unless you're a compulsive tinkerer and are willing to replace all the electronics. Anyway, back to topic, its a PCM of sorts transmitter. It actually has two additional channels that are not wired in the transmitter. The transmitter and receiver use the off settings of these channels to negotiate link...that's right, they actually look for those two unused channels and expect to see them as unused. This really doesn't have anything to do with the PIC but I thought it was worth mentioning.

The radio we're learning about in the joystick interface forum is a newer version that is being released with the Walkera #35 (and others), On a side note this transmitter supposedly supports CCPM via a dip switch... no breath holding there for me.

Its my understanding that they abandoned the unused channel syncs and did away with whatever wierd PCM implementation they had going. The #35 needs those two additional channels for Throttle/Pitch curve adjustment, as well one for switching between what they call "normal" flight ie - throttle curve of 0 25 50 75 100 or something similar and their acro mode which sets the curve at 100 100 100 100 100. Don't know about ya'll, but that's one transistion no beginner should ever have to make.

Now to get back on topic. It also looks like the output from the supplied PIC is different. I should be able to provide more info once I have my #35... bought it for scrap / playtime... unknowning at the time I'd be revisiting the FMS forums and reading about it.

[bcp]

I too recently purchased a walkera chopper with transmitter and find that FMS is not responding to the transmitter. I downloaded and ran Eric Brouwers' PIC tester software and find that the graphic responds to all joystick movements. I check the comms setup and the Baud rate and comm port are all OK.
Being a complete novice to the RC world I think that maybe my mapping may be incorrect or there is a software config problem somewhere. I am running 98SE and the fact that the PIC tester checks out OK makes me think that it is program orientated.
Would appreciate some input.
bcp

[phildc]

Try to post the transmitted data as explained in:
FMS Forum » Interface-Hardware » Joystick-Interface » Zhen Hua Protocol: help understand

It could help.

[Eric Brouwer]

[ShellDude]

I got my Walkera #35 heli a couple days ago. It came with an updated Zhen Hua transmitter. They've switched to a PPM signal and added two pots for pitch and throttle curve adjustment.

Beyond that its basically the same transmitter by appearance.

The PIC protocol has changed. Actually I couldn't make heads or tails of any of the data its spitting out.

Doesn't work in Eric's tester and RS232anaylzer just spits out random numbers with no consistency.

Tried both 9600 and 19.2

[phildc]

Could you just copy these 'random numbers'? So we can have a look.

[ShellDude]

19.2

All centered - 0% throttle
0 0 0 0 0 0 128 0 128 0 0 0 0 0 0 0 0 0 128 128 128 0 0 0 0 0 0 0 0 0 0 128 0 0 0 0 0 0 0 128 128 128 0 0 0 0 0 0 0 0 128 0 128 0 0 0 0 0 0 0 0 0 128 128 128 0 0 0 0 0 0 0 0 0 0 128 0 0 0 0 0 0 0 128 128 128 0 0 0 0 0 0 0

All centered - 100% throttle
0 0 0 0 0 0 128 0 128 0 0 0 0 0 0 0 0 0 128 128 128 0 0 0 0 0 0 0 0 0 0 128 0 0 0 0 0 0 0 128 128 128 0 0 0 0 0 0 0 0 128 0 128 0 0 0 0 0 0 0 0 0 128 128 128 0 0 0 0 0 0 0 0 0 0 128 0 0 0 0 0 0 0 128 128 128 0 0 0 0 0 0 0

9600

All centered - 0% throttle
224 0 3 56 128 0 0 128 128 128 56 0 0 0 0 0 0 0 0 0 0 7 0 0 0 0 0 56 135 128 0 224 0 0 0 0 0 56 112 14 28 0 0 0 0 0 0 0 0 0 0 28 14 96 0 0 0 0 128 56 135 0 224 0 3 56 128 0 0 128 128 128 56 0 0 0 0 0 0 0 0 0 0 7 0 0 0 0

All centered - 100% throttle
0 0 0 0 0 0 128 128 128 56 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 56 135 128 0 0 0 0 0 0 0 56 112 14 28 0 0 0 0 0 0 0 0 0 28 0 12 96 0 0 0 0 128 56 135 0 0 0 0 0 0 0 128 128 128 56 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 56 135 128 0 0 0 0

[phildc]

I see. Unusable. Still a mystery...