Need help with Zhen Hua

[ShellDude]

Ok, I know this is a REALLY old topic, and there are numerous references to this transmitter throughout the site, but I'm at a complete dead-end.

I run XP x64 (AMD Athlon 64) so I can't cheat and use PPJoy as XP x64 requires all device drivers to be compiled for 64 bit.

Now, this is where things get wierd. I've got a couple PIC testers and they report everything working fine.

RS232analyser.exe reports activity from the transmitter. Its pretty clear by watching it how the encoding is working... basic linear scale for each channel depending on position.

But FMS 2 Alpha 85 refuses to acknowledge the interface. Its like flat out ignores all data from the serial port.

So, I searched the forums and came across FMS Serial PIC Interface Tester... I assume this from one of the project contributors so I download and install it... notice that's its a cute vb program from the installer --- anyway... it works. It recognized the radio, calibrated it, and everything.

One thing I did notice in the FMS PIC tester is that there is a modal window that opens showing a wiring diagram for the Zhen Hua PIC interface. I haven't taken the time yet to pop open the rs232 connector to look at my pinouts, but I assume since it works in the little tester it should work just fine in FMS too.

What am I missing? I've also tried the "stable" Beta 7 version of FMS and get the same results.

Any help, and again I apologize for the redundancy of this topic, is greatly appreciated.

Shell

[ShellDude]

I should add that I just swapped the red wire with the "alternate" location illustrated in the FMS PIC tester.

Everything still is good to go in the Tester, but FMS refuses to recognize the connection. I wish I could get a 64 bit version of portmon going as it looks a lot like FMS isn't opening the COM port.

[phildc]

Zen Hua:
I think it is coded another way, some bit swapping a;s.o.
Could you append some (say 20) of the values you got with RS232Analyser?
For FMS you should see a synch (FF hex=255dec or FE=254) and a number of channels between two successive synchs. The channel values at rest should be around 128 (on a 1-255 scale), except the throttle that will can be anywhere on the scale.
If you have othet values, and they do not change proportionally with the stick position, you have a problem; because the Zen Hua coding (or protocol) is only translated by PPJoy to a joystick-type signal, and you tols us PPJoy is not good for your system. I think Zen Hua synch is any number above 240, and you will see a fixed number of values between 2 of these synch's.

Phil.

[phildc]

Sorry, reading your post again slowly... you told us you see a linear encoding.
Do you get a FF=255 at 19200 bps, as synch character, or FE=254 at 9600 which are the FMS standards?
Please copy some 20 values, so I can comment.
Thks,
Phil.

[phildc]

I wrote PPJoy, but it is PPJoyComm that would understand the Zen Hua signal(signal coming to the pin 2 of the D Sub 9).
Phil.

[ShellDude]

[phildc]

[ShellDude]

Here's a sample of what RS232analyser.exe is seeing

19200/N/8/1

Transmitter configured for Mode 2

Full down elevator (remaining controls centered)
239 129 44 17 126

all controls centered
239 129 102 161 126

full up elevator (remaining controls centered)
239 129 99 33 126

Is this stuff BCD encoded or something? The linearness I was referring to was in PIC Tester for FMS (it was written by E.Brouwer).

Here's a screenshot

[phildc]

Ok, the encoding was verifies by the 'tester' of Eric Brouwer...
Must be some special encoding of the channel values.

So, to my knowledge, only solution is PPJoyCom. (creating a virtual joystick)

Did you try this one on your system? Must be more compliant than PPJoy that uses tries to use interrupts to decode a PPM signal (LPT pin 10 in parallel, COM pin 9 in serial). With PPJoyCom you read standard serial input on a COM port (pin 2 of a serial D Sub 9)
Good luck!
And let us know the result!
Phil.

[ShellDude]

That's the thing. Its a 32 bit device driver. XP x64 will only work with x64 compiled device drivers.

[phildc]

Here is an interpretation of the previous test results (done by ShellDude with RS232Analyser.exe) :

controls centered, except full down elevator
239 129 44 17 126 gives <= test values
synch 129 36 136 126 elevator = 36 ? <= calculated values

controls centered
239 129 102 161 126
synch 129 102 133 126 elevator = 102 ?


controls centered, except full up elevator
239 129 99 33 126
synch 129 198 132 126 elevator = 198 ?


is channel 2 the elevator?
channels 1 and 4 don't move
channel 3 moves a little bit (between 132 and 136)

Zhen Hua 5 byte protocol:
synch hexEF = dec 239
4 channels with the order of bits inverted.

Is this correct?.
This could open the way for new developments (Eric Brouwer already did)

Philippe.

[ShellDude]

If I recall correctly, and I can confirm once I get home:

Channel 1 - throttle
Channel 2 - elevator
Channel 3 - aileron
Channel 4 - rudder

[ShellDude]

Would it be possible for you to post the formula you're using to decode the data?

[phildc]

"Zhen Hua 5 byte protocol:
synch hexEF = dec 239
4 channels with the order of bits inverted"

It's as simple as that.

A few samples:

129 = x81 = 1000 0001 rev-> 1000 0001 = x81 = 129 (unchanged)
161 = xA1 = 1010 0001 rev -> 1000 0101 = x85 = 133

seems to be an error with 44 !? All done very quickly, and by hand...

[ShellDude]

ah, I read "inverted" and was simply trying to multiple by -1... wasn't getting too far, in decimal, hex, or binary.

Inverted Bits typically means

1000 0001 becomes 0111 1110

Reversed ... now that's a bit different. Thanks for the clarification.