RunRyder RC
 7  Topic Subscribe
WATCH
 5 pages [ <<    <     3      4     ( 5 )    >    >> ] 34762 views POST REPLY
Scorpion Power Scorpion Power
HelicopterRadio - Servo - Gyro - Gov - Batt › Decoding Futaba PCM 1024Z
11-11-2003 07:53 PM  13 years agoPost 81
Angelos

rrKey Veteran

nr Oxford, OX11, UK

My Posts: All  Forum  Topic

I checked the ECC calculation. Indeed it is as the smartpropo engineer tells us, amazing!
Have you not noticed that these values have one bit shift among them? The algorithm is not ECC and does not correct any errors. It is an good old CRC that is excellent at detecting errors but not correcting them. The polynomial is:

f(x)= x^8 + x^6 + x^5 + x^3 + x + 1

This means that is you shift and XOR the bit stream as it comes in with 01101011 when the message is completed you should have 0.

So the smartpropo guy either didn’t see what he had in front of him or he made a stupid CRC implementation.

-Angelos

PM  EMAIL  GALLERY  Attn:RR  Quote
11-11-2003 08:09 PM  13 years agoPost 82
Angelos

rrKey Veteran

nr Oxford, OX11, UK

My Posts: All  Forum  Topic

Try this...
http://duchon.umuc.edu/Web_Pages/du...iftRegister.htm

Enter polu 101101011 and message 101000111110001010000001 (Frederic's first data set).

There is a problem with my explorer and applet does not run but I am sure the result will be zero.

If you enter only the first 16 bits as a message 1010001111100010 the result should be the following 8 bits 10000001

-Angelos

PM  EMAIL  GALLERY  Attn:RR  Quote
11-12-2003 05:07 AM  13 years agoPost 83
George You

rrNovice

West Pacific Island

My Posts: All  Forum  Topic

JR's 5b/8b encoding?

Hi all-
I have also checked the smartpropo's JR PCM decoding. The table there implies that JR is using 5b/8b encoding. However it is wierd that unlike Futaba's 6b/10b encoding table, the encoded data contains single 0 ans 1s. Angelos told us that the use of 6b/10b can reduce the bit bandwidth by half and it really makes sense. But what about JR's encoding table? I scoped JR's pulse and found they have bit clock ~165uS, while minimum time interval between transitions is ~330uS, just like what Futaba does, but a little bit longer. Any comment on this 5b/8b scheme??
for recent days I have been thinking about the use of 6b/10b encoding scheme and completely agrees with what Angelos said. It would be possible to send more bits than occupied bandwith if the transimission media had good SNR.

PM  EMAIL  Attn:RR  Quote
11-12-2003 08:53 AM  13 years agoPost 84
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Angelos

Only the first 16 bits are used to calculate the ECC. The last 8 bits are the ECC itself. So I dont quite follow you.
The Smartpropo guy implemented the code BEFORE he found out the ECC.
The crc webpage looks nice, and made thing clearer for me what CRC is. Thanks! The java applet doesn't work for me either.

I still think that the futaba ECC is an ECC and not a CRC. You can find out which bit is wrong by looking up the XOR of the ECC calculated from the first 16 bits with the ECC as it was transmitted in the last 8 bits. The bit corresponding to that number is the bit that was likely flipped in the transmission process.

I agree it's not 'excellent' but I have no idea how good this can get. In my report I already mentioned that correcting 2 bits is already quite a gamble with this code.

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-12-2003 10:22 AM  13 years agoPost 85
Angelos

rrKey Veteran

nr Oxford, OX11, UK

My Posts: All  Forum  Topic

Only the first 16 bits are used to calculate the ECC. The last 8 bits are the ECC itself. So I don’t quite follow you.
On the TX side you feed your 16bit message into the CRC shift register bit by bit. When all message bits are sent the CRC register contains the CRC. You continue to feed 0's in the CRC shift register and you empty the CRC register on your transmission line one bit at a time.

On the receiver side, you have two options... the first is usually implemented by people who don't understand the maths behind CRC. Again you feed your message into the CRC register. When the message is completed you compare the contents of the CRC register with the received CRC.

The magic of CRC... The second method is really cleaver. You shift the entire message and CRC into the CRC register. This means that this process can be done on the fly. The moment your last bit is shifted in the CRC register you already know if the message was correct or not. If the CRC register is 0 then the message is correct.
The java applet doesn't work for me either.
Strange! I used it last December to confirm I had the right polynomial.
I still think that the futaba ECC is an ECC and not a CRC.
The CRC works perfect and I know that CRC does not do reliable error correction. You could possibly identify which bit is wrong but I can fabricate a message with an error at such location that the smartpropo algorithm will tell you that another bit is wrong. Also multiple bit errors could be misinterpreted as a single bit error which the receiver would attempt to fix. So, do you want a receiver which will be happy to accept frames with errors? If it was my receiver design I would go for a proper ECC algorithm.

PM  EMAIL  GALLERY  Attn:RR  Quote
11-12-2003 04:51 PM  13 years agoPost 86
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Hi Angelos

I wondered about the following
"I can fabricate a message with an error at such location that the smartpropo algorithm will tell you that another bit is wrong."
A message with only ONE bit wrong? I would like to see that. TWO bits? I don't believe that either. For more than that, sure. But every ECC or CRC has this problem. So I miss your point here.

Or do you mean that the probability of 1/256 just is not high enough for error correction? And that they should more bits?I dont believe it's possible to create a more solid code with 8 bits? The 16 bit data has 8 bits more than the ECC,thus every ECC can be correct for on average 256 different datas, and on top of that the ECC itself might be transmitted wrong. But I'm not an expert on this, so please tell me what I'm missing...
"Also multiple bit errors could be misinterpreted as a single bit error which the receiver would attempt to fix. So, do you want a receiver which will be happy to accept frames with errors? If it was my receiver design I would go for a proper ECC algorithm."
Yes if at least 3 bits are wrong in the data, or I guess two bits in the ECC.But again, every code having less ECC than data bits seems to have this property?
And what is the proper ECC algorithm according to you ?

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
11-12-2003 05:14 PM  13 years agoPost 87
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

My fingers start itching already. Can I get a copy of source & compiled code?
Sure! I am still working on it though. Do you want it now or can you wait a week or two?
This is how it looks now (it also shows the bits between the frames, the sync inversion, the time, and the channels are correct now):
== SYNC = POS == Time:7983.75ms == #Frames:0279 ==========
000000 FrameType: EVEN
11 Meaning unknown (yet)
0011001100 => PCM byte 101000
0001100111 => PCM byte 100010
0011110000 => PCM byte 110010
0011000111 => PCM byte 100000
aux= 2 ecc=160 A2= 556 D1= 8
0011111111 => PCM byte 001000
1100011100 => PCM byte 011100
0001111000 => PCM byte 110001
0011111100 => PCM byte 010000
aux= 0 ecc= 80 A4= 460 D3= 8
0011001100 => PCM byte 101000
0000000111 => PCM byte 111111
0011100000 => PCM byte 110011
1111001100 => PCM byte 010100
aux= 2 ecc=212 A6=1020 D5= 8
0011111111 => PCM byte 001000
0011111100 => PCM byte 010000
0001110000 => PCM byte 111001
0000111100 => PCM byte 110000
aux= 0 ecc=112 A8= 270 D7= 8
------ Time=8009.25
001111
== SYNC = NEG == Time:8012.55ms == #Frames:0280 ==========
000011 FrameType: ODD.
0011001100 => PCM byte 101000
0000011111 => PCM byte 100110
1111100111 => PCM byte 000011
0011111100 => PCM byte 010000
aux= 2 ecc=208 A1= 608 D2= 8
0011111111 => PCM byte 001000
1110011000 => PCM byte 011101
0011000111 => PCM byte 100000
1110000000 => PCM byte 110110
aux= 0 ecc= 54 A3= 472 D4= 8
0011001100 => PCM byte 101000
1111110011 => PCM byte 000001
0001111000 => PCM byte 110001
1100001100 => PCM byte 101110
aux= 2 ecc=110 A5= 28 D6= 8
0011111111 => PCM byte 001000
0001110000 => PCM byte 111001
0011100000 => PCM byte 110011
0001111100 => PCM byte 100101
aux= 0 ecc=229 A7= 924 D8= 8
------ Time=8037.45
1100
== SYNC = NEG == Time:8040.75ms == #Frames:0281 ==========
000000 FrameType: EVEN
11 Meaning unknown (yet)


Frederic

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
11-12-2003 05:16 PM  13 years agoPost 88
FredericG

rrNovice

Belgium

My Posts: All  Forum  Topic

What amazes me is that all positions are even... could it be that my TX (FC-16) only has 9 bit ADCs?

Frederic

PM  EMAIL  HOMEPAGE  Attn:RR  Quote
11-14-2003 09:25 AM  13 years agoPost 89
Angelos

rrKey Veteran

nr Oxford, OX11, UK

My Posts: All  Forum  Topic

A message with only ONE bit wrong? I would like to see that. TWO bits? I don't believe that either. For more than that, sure.
The CRC guarantees that all single bit errors will be detected. This means that if the CRC register is initialised to zero before the message is received, it will be zero again after the message + CRC are received. However, there is a very large number of possible messages and a very large number of possible errors. The 8-bit CRC register can only have 255 combinations to indicate these errors. I am sure there are more than one message/error combinations that produce the same value in the CRC register.

PM  EMAIL  GALLERY  Attn:RR  Quote
11-14-2003 05:13 PM  13 years agoPost 90
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Angelos,
I am sure there are more than one message/error combinations that produce the same value in the CRC register.
With the Futaba ECC code, every 1-bit error produces an unique code and thus can be recognised corrected. So that's nothing less than the CRC you mention. With 2 bits wrong, there will be a non-zero but not unique code remaining, so you can still detect the err but not correct it anymore.
However, there is a very large number of possible messages and a very large number of possible errors. The 8-bit CRC register can only have 255 combinations to indicate these errors.
There are 16*15/2=120 possible connections with two bits, so this is no miracle that the ECC code still works as error detector.If I understand you right you say that CRC has a problem already with two bits, so in that case the Futaba ECC would be better?

With more bits wrong I think every 8-bit code (CRC or ECC) has problems.

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
12-01-2003 12:18 AM  13 years agoPost 91
E.Klinke

rrNovice

71088 Holzgerlingen, Germany

My Posts: All  Forum  Topic

Hi Angelos, Frederic and Wouter (alphabetic order)

I am wondering if y'all are still interested in the subject. I definitely am.

I came across this thread only yesterday while looking for info on JR SPCM encoding/decoding. I had finished a micro controller program to decode Futaba PCM1024 and thought it might be a good idea to also enable JR SPCM. I was really electrified and read the whole thread from beginning to the end. You can imagine I have a few remarks on subjects you were discussing - like the following:

Delta codes: I do not agree that delta code 0 is omitted. I have seen and recorded all possible delta codes including 0. I saw them when the difference between successive absolute values for that channel were above x'F0' .

Btw., my delta table is off by 4 as compared to Wouter's suggestion.
it looks the following:

F E D C B A 9 8 7 6 5 4 3 2 2 0
-92 -68 -48 -32 -20 -12 -8 0 8 12 20 32 48 68 92 120

I derived it the following way:
I generated stimulus by using 'Servo Test' in the TX and iterated the servo speed.
I recorded with my micro the differences between successive absolutes for one channel together with the delta code for that channel transmitted in the frame between. From these data I derived the upper and lower limits of differences for all delta codes. Now, since the delta is applied midway between the two absolute values they were derived from, it will statistically create the least error if the receiver applies half of the mean difference.
I reallized that Futaba had chosen to make the range of differences for each delta code 8 bigger than the previous one as you move away from delta code 8. This would result in a formula like
Table[ D] = (8-D)x4.
This results in Wouter's table. But since Futaba choose to create a 'calm zone' where they do not apply any delta if the difference between consecutive absolute transmissions is not greater then 7, it is necessary to 'make up' for it when being outside this zone.
That made me come to the formula
Table[D] = (8-D)x4 + C
where C = 0 if D=8; C=+4 if D is less than 8; and C = -4 if D is greater than 8.

Subject CRC: My implementation is the following:

CRC = CRCTable[CRCTable[Byte1] xor Byte2]

this is one line in C and the following 4 lines in 8051 assembler if the 256 byte table is in code space.

mov DPTR,#CCF0CRCTab1 ;
mov a,RxInData ;
movc a,@a+DPTR
xrl a,RxInData+1

This is the table:

;
CCF0CRCTab1:
DB 000h,06bh,0d6h,0bdh,0c7h,0ach,011h,07ah ;00
DB 0e5h,08eh,033h,058h,022h,049h,0f4h,09fh ;08
DB 0a1h,0cah,077h,01ch,066h,00dh,0b0h,0dbh ;10
DB 044h,02fh,092h,0f9h,083h,0e8h,055h,03eh ;18
DB 029h,042h,0ffh,094h,0eeh,085h,038h,053h ;20
DB 0cch,0a7h,01ah,071h,00bh,060h,0ddh,0b6h ;28
DB 088h,0e3h,05eh,035h,04fh,024h,099h,0f2h ;30
DB 06dh,006h,0bbh,0d0h,0aah,0c1h,07ch,017h ;38
DB 052h,039h,084h,0efh,095h,0feh,043h,028h ;40
DB 0b7h,0dch,061h,00ah,070h,01bh,0a6h,0cdh ;48
DB 0f3h,098h,025h,04eh,034h,05fh,0e2h,089h ;50
DB 016h,07dh,0c0h,0abh,0d1h,0bah,007h,06ch ;58
DB 07bh,010h,0adh,0c6h,0bch,0d7h,06ah,001h ;60
DB 09eh,0f5h,048h,023h,059h,032h,08fh,0e4h ;68
DB 0dah,0b1h,00ch,067h,01dh,076h,0cbh,0a0h ;70
DB 03fh,054h,0e9h,082h,0f8h,093h,02eh,045h ;78
DB 0a4h,0cfh,072h,019h,063h,008h,0b5h,0deh ;80
DB 041h,02ah,097h,0fch,086h,0edh,050h,03bh ;88
DB 005h,06eh,0d3h,0b8h,0c2h,0a9h,014h,07fh ;90
DB 0e0h,08bh,036h,05dh,027h,04ch,0f1h,09ah ;98
DB 08dh,0e6h,05bh,030h,04ah,021h,09ch,0f7h ;A0
DB 068h,003h,0beh,0d5h,0afh,0c4h,079h,012h ;A8
DB 02ch,047h,0fah,091h,0ebh,080h,03dh,056h ;B0
DB 0c9h,0a2h,01fh,074h,00eh,065h,0d8h,0b3h ;B8
DB 0f6h,09dh,020h,04bh,031h,05ah,0e7h,08ch ;C0
DB 013h,078h,0c5h,0aeh,0d4h,0bfh,002h,069h ;C8
DB 057h,03ch,081h,0eah,090h,0fbh,046h,02dh ;D0
DB 0b2h,0d9h,064h,00fh,075h,01eh,0a3h,0c8h ;D8
DB 0dfh,0b4h,009h,062h,018h,073h,0ceh,0a5h ;E0
DB 03ah,051h,0ech,087h,0fdh,096h,02bh,040h ;E8
DB 07eh,015h,0a8h,0c3h,0b9h,0d2h,06fh,004h ;F0
DB 09bh,0f0h,04dh,026h,05ch,037h,08ah,0e1h ;F8

I also have a version where the table resides in external ram. In this case I generate the table using the following code fragment:



;-----------------------------------------------------------------
; Generate CRC Table to allow fast calculation of PCM1024 CRC by SLIH
;-----------------------------------------------------------------
;
GenCRCTable: mov DPTR,#HIGH(CCF0CRCTab) ; load DPTR to start of CRC table to be built
mov r3,#000h ; Table Index
mov r4,#000h ; Loop Counter for 0100h table entries

; To calculate the table entry at offset i, it is necessarry to shift i eight times and if
; a b'1' was shifted out, do an additional xor with the polynom (in our case #06bh).

GenCRCTable0: mov r2,#008h ; 8 bits in a byte
mov a,r3

GenCRCTable1: clr c
rlc a
jnc GenCRCTable2 ; Skip xor if bit 7 was a b'0'
xrl a,#06bh
GenCRCTable2: djnz r2,GenCRCTable1 ; Next Bit
movx @DPTR,a
inc DPTR
inc r3 ; Next Index
djnz r4,GenCRCTable0 ; loop if not done
;
;-----------------------------------------------------------------

Sorry I can not get the formatting right but I hope you can read the code anyways.

I have also implemented a 'Multiswitch/Multiprop' decoding functionality and it works well. I want to use it to influence the parameters like P,I and D of the automatic flight control I am developing for my glider.

Enough for today - it is late and I need to catch some sleep.

PM  EMAIL  Attn:RR  Quote
12-01-2003 01:29 PM  13 years agoPost 92
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

Hi Klinke!
Yes we are still active on this, check out the 1024PCM PART II a few lines higher on the list.

Maybe you can copy your comments that you posted again, in that current thread? That's where the action is now!

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
12-01-2003 02:58 PM  13 years agoPost 93
w.pasman

rrElite Veteran

Netherlands

My Posts: All  Forum  Topic

EVERYONE

PLEASE CONSIDER THIS THREAD CLOSED. WE CONTINUE THE WORK IN THE PCM-1024 PART II THREAD

PM  EMAIL  HOMEPAGE  GALLERY  Attn:RR  Quote
WATCH
 5 pages [ <<    <     3      4     ( 5 )    >    >> ] 34762 views POST REPLY
Scorpion Power Scorpion Power
HelicopterRadio - Servo - Gyro - Gov - Batt › Decoding Futaba PCM 1024Z
 Print TOPIC  Make Suggestion 

 7  Topic Subscribe

Saturday, October 21 - 1:16 pm - Copyright © 2000-2017 RunRyder   EMAILEnable Cookies

Login Here
 New Subscriptions 
 Buddies Online