RC Tanks Australia Forum

Hi,

I'm attempting to modify a Heng Long tank to operate using my own control board. I have considered building my own circuitry to control the motors etc., but was wondering if it would be easier to leave the "RX" control board in place and get my board to command the vehicle in place of the normal RC receiver board.

I haven't managed to find any information on how the receiver board talks to the RX board, but I have found the "HC2RL" thread in this forum and it appears that it's a circuit that does what I'm trying to do!

Does anyone here know what protocol the normal Heng Long receiver board / the HC2RL uses to communicate with the RX board? Is it something as simple as an RS232 serial connection, or something more complicated?

Thanks in advance if you're willing and able to help me out here!

Hello tsuki,

I have been looking at the same thing your trying to do except I want to control the tank from the pc with a joystick and wireless cam and also getting a more realistic running speed.

Signal protocol that I have found is that it is a PCM signal using manchester encoding, full bit time varies from 570 - 600 ms, I wrote a time based decoding program in mikroC using a 16f628a it doesn't work to well because of the bit time varying, but at least I got some of the codes for ignition, turret control, cannon fire and machine gun and some basic movements, my only problem is I can't workout the checksum algorithm, so its been put on hold.

These are the 8bit codes I worked out which I send to another pic to encode the signal and tap into the heng long transmitter.

idle signal 0xFE3C0F00;
ignition 0xFE3C10B0;
machine_gun 0xFE3C107C;
cannon 0xFE3E1030;
turret_left 0xFE3C9018;
turret_right 0xFE3D103C;
turret_down 0xFE3C5028;
turret_fire 0xFE3C3030;
fwd_slow 0xFE301008;
rev_slow 0xFE3C1038;
left_slow 0xFE3C081C;
right_slow 0xFE3C1620;

I have added a jpg file with a description of the signal and bit patterns, hope this helps you out
maybe you could work out the checksum method, because it beyond my payscale.

regards ancvi_pIII

Wow, you've certainly got further than I have!

I've had the output of the TK board on a scope and seen exactly the bit patterns you described, but my scope can only trigger on edges rather than the timed space between the packets, so I've been unable to properly study what it's sending.

It looks like you've got all the basic commands figured out, so at the very least it should be possible to command one thing at a time using those known codes -- but you're right, it would be handy if we could figure out the checksum algorithm so we could send combinations of the known commands.

I'll see if I can figure it out, but checksum algorithms -- even this one, that's only 4 bits from 17 bits of unique data -- can be really hard to figure out!

IMAG0048 (1).jpg

Hello tsuki,

what you need is a logic analyzer, the one I use is a combination oscilloscope & logic analyzer from Polabs
heres the link http://www.poscope.com/poscope-basic-2, Jaycar sell them.

if you want a copy of my mikroC code I can send you a copy, maybe you can do a better job of my decoding routine.

I certainly would like to find the checksum method, the only thing I found is that it maybe some type of xor checksum or
lrc checksum.

If you want to know where to tap into the transmitter pcm signal see the attached photo

I've spent an hour or so trying various ideas for the checksum, with no luck so far. I'll give it another try when I have more coffee inside me!

A couple of questions before I do:

1) Are those four bytes definitely a checksum, rather than some other unknown data? (e.g. have you tried setting one of the checksum bits wrongly and seen the tank refuse the command?)

2) Is the "idle" message you listed the command before the tank has its "engine" switched on, or afterwards? It looks from the bit patterns that the "template" for a running-but-doing-nothing tank should be 0xFE3C1000 (with whatever checksum needs to be overlaid on that), but I don't see that in your table, so I was wondering if the fact that b12-b8 were so different to "normal" in the "idle" message could be because the engine was switched off?

Hello tsuki,

question 1: Since I could not work out the checksum I put this project on hold, so its been a while since I worked on it, I think I have tried that but the command was ignored by the rx18, and from what I have found on the internet
bits 5 - 2 is the checksum.

question 2: With the heng long transmitter turned on, the idle message I get from my decode program from the output
of the tk-yl101 receiver is 0xFE3C1038, this message is continually sent when no other commands are sent, when I bypassed the tk-yl101 and sent turn right commands directly to the rx18 with my encoding program then stop with the idle command 0xFE3C1038 the tank continued turning, it was only with turn right.

I could not figure out what was going on until I found this pdf document on rcuniverse forum which showed the bit patterns
and what they meant, they appeared to be different to what I was getting on my decode program and seeing on my logic analyzer, the idle pattern it showed was 0xFE3C0F00 as opposed to 0xFE3C1038. From memory when trying to get the the timing right on my decode program I occasionly did get 0xFE3C0F00 but I thought it was an error in my timing, so maybe there are two idle commands with the main one being 0xFE3C1038, they both work.

Using 0xFE3C0F00 after the turn right command stopped the motor, so with my PC program when all motor commands have
ceased I send the idle command 0xFE3C0F00 then 0xFE3C1038, which will continually be sent until another command is received.

Hope this info helps.

Thanks for all your help, ancvi_pIII! I'm pleased to say that I now have a working replacement for the TK board, using the codes from your post and the attached image/PDF. I'm afraid I haven't cracked the checksum yet - still working on that!

Hello tsuki,

Good to see you got it working with your interface card, it would be good to find a way to calculate the checksum so that you could have full speed control and control of other functions of the tanks as opposed to my method of just recording the bit sequence for each command and then resending.

ancvi_pIII,

One more quick question - have you had your tank driving around with the tracks on using the left/right/reverse commands you listed?

Using your codes my tank drives forwards properly (providing around 4.5V to each motor), but when I send the left/right/reverse commands I get between 0.25V and 1V on each motor. This is enough to spin the wheels when the tracks are off, but once the tracks are attached it doesn't have enough force to drive the tank.

Thanks,

Ian

Hello tsuki,

Even when battery is close to flat, I can get the tank to move and turn with the tracks on at the slow speeds.

I tried uploading a video of my tank running with my setup, but the forum would not accept the upload.

Do you have metal tracks on your tank? I think they require more power from the motors to get moving.

I have a 3:1 gearbox on my Panzer III, from your video it looks like you have the standard metal gearbox, anyway I recorded the codes for faster forward, reverse, left and right movements, I tested them from my PC to heng long transmitter and they work.

Forward Fast 0xFE28102C
Reverse Fast 0xFE541000
Right Fast 0xFE3C1818
Left Fast 0xFE400608

Let me know if they work

The above codes may give you some more ammunition to crack the checksum.

Also it would pay to put a fan on the RX18 board to cool the motor controller board as they get quite hot.
see picture.

Hope this helps