I believe I may have found the solution to the checksum, I figured it out by adding your codes to the list.
Disregard the preamble byte 0xFE bits b31 - b24 in the calculation and treat
b23 - b20, b19 - b16, b15 - b12, b11 - b8, and b7 - b6 as 4 bit codes then XOR b23 - b20 with b19 - b16
then XOR the result with the next 4 bits b15 - b12 and so on.
for example the the idle codes
mine FE3C1038
3 0011
C 1100 - XOR becomes 1111
1111
1 0001 - XOR becomes 1110
1110
0 0000 - XOR becomes 1110
1110
0 0000 b7 - b6 as 4 bits XOR becomes 1110 checksum b5 - b2 is 1110
your idle code FE40121C
4 0100
0 0000 - XOR becomes 0100
0100
1 0001 - XOR becomes 0101
0101
2 0010 - XOR becomes 0111
0111
0 0000 b7 - b6 as 4 bits XOR becomes 0111 checksum b5 - b2 is 0111
I even tried my forward slow which is FE301008 with the machine gun bit b6 set which becomes FE30104C
3 0011
0 0000 - XOR becomes 0011
0011
1 0001 - XOR becomes 0010
0010
0 0000 - XOR becomes 0010
0010
1 0001 b6 set XOR becomes 0011 checksum b5 - b2 is 0011 so code sequence is FE30104C
All I need to do know is figure out how to set or clear individual bits in my PC software
I have tried the FE30104C and the tank moves forward and fires the machine gun sound.
I tried setting the turn turrett right bit b16 as well giving code FE311048 but at the moment
I have the turrett off doing a servo control of cannon recoil modification so I could not confirm if the
turrett turns with tank moving forward firing machine gun.
regards Andrew
Statistics: Posted by ancvi_pIII — Thu Jun 28, 2012 6:29 pm
]]>
I tried to find a logic analyser to do the job, but I couldn't find one -- so I wrote my own in software
I used a National Instruments data acquisition device and a bit of LabVIEW code on the back end to sample, then decode, each signal.I posted all the details on my blog, where you can download the source code if you have access to LabVIEW and a suitable DAQ device: http://blog.ianrenton.com/raspberry-tan ... ode-redux/
Statistics: Posted by tsuki — Thu Jun 28, 2012 3:43 pm
]]>
I tried some of your codes and guess what, they work, I used the ignition, left-fast and recoil codes on my PC program
which sends the commands via rs232 to my encoding PIC which then sends the correct signal to my HL transmitter.
Did you use a fixed timebase routine to decode the hl signal?
In my PIC program I initially use a rising edge interrupt on the first part of the preamble then use a timer1 interrupt set to about 585ms to detect if the signal is either at logic 1 or 0.
As I stated in earlier posts the HL signal varies a little bit in its full bit time so with my time based routine it only has to be
slightly off and I get false readings.
What method for decoding did you use on your interface board?
regards Andrew
Statistics: Posted by ancvi_pIII — Thu Jun 28, 2012 9:11 am
]]>
Rather than bug you again, I figured I'd just stop being lazy and sniff the codes my tank uses myself! This is what I came up with:
FE40121C idle
FE401294 ignition
FE400608 left-slow
FE400010 left-fast
FE401930 right-slow
FE401E2C right-fast
FE200F34 forward-slow
FE000F3C forward-fast
FE580F08 backward-slow
FE780F00 backward-fast
FE408F0C tur-left
FE410F28 tur-right
FE404F3C tur-elev
FE442F34 shoot
FE440F78 machinegun-sound
FE420F24 recoil
I'll plot the bit patterns next to yours when I have time, and see if I can figure out a common pattern. Of course, that's also 17 more data points towards cracking that checksum algorithm!
Statistics: Posted by tsuki — Wed Jun 27, 2012 7:38 am
]]>
To show video you should upload the video to YouTube and then place the YouTube id number for the video witin the [YouTube] tags.
Cheers
Kevin G
Statistics: Posted by Phyrephish — Sat Jun 23, 2012 1:39 pm
]]>
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
Statistics: Posted by ancvi_pIII — Sat Jun 23, 2012 1:05 pm
]]>
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
Statistics: Posted by tsuki — Fri Jun 22, 2012 10:59 pm
]]>
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.
Statistics: Posted by ancvi_pIII — Sat Jun 16, 2012 9:38 am
]]>
Statistics: Posted by tsuki — Fri Jun 15, 2012 6:42 am
]]>
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.
Statistics: Posted by ancvi_pIII — Sun Jun 10, 2012 9:49 am
]]>
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?
Statistics: Posted by tsuki — Sat Jun 09, 2012 4:42 pm
]]>
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
Statistics: Posted by ancvi_pIII — Sat Jun 09, 2012 4:31 pm
]]>
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
Statistics: Posted by tsuki — Sat Jun 09, 2012 7:49 am
]]>
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
Statistics: Posted by ancvi_pIII — Thu Jun 07, 2012 3:21 pm
]]>
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!
Statistics: Posted by tsuki — Tue May 29, 2012 7:46 am
]]>