rrTV-PHOTO   New HD TV
HOME   rrTV-PHOTO   GALLERIES   MY GALLERY   HELP-FAQ
myHOME PM pmRR MEMBERS 714 ONLINE 46 EVENTS SEARCH REGISTER  START HERE
 
9 pages [ <<    <     3      4     ( 5 )     6      7     NEXT    >> ]13802 viewsPOST REPLY
A Main Hobbies . Boca Bearings . Modefo's RC Helicopters

.
.
Radio - Servo - Gyro - Gov - Batt > Starting a Home-Brewed PCM Receiver Project
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, Gang!

Tom: Awesome! I'd love to be able to work with you on this one, but unfortunately, this won't be a candidate for wave soldering. With all the SMT parts, it'll be necessary to do IR reflow. I'll definitely keep that in mind for other projects, though. Thank you!

Angelos: Kick ass! Congratulations on the great progress! I'm not yet to the stage of even thinking about UI, but that's a terrific start. Well done!

Have Fun!
MarkF
10-27-2003 Over year old.
HOMEPAGE  
 
 
Duranza
Heliman
Location: Miami, FL

this is cool stuff

i'm a electronics guy myself. I just never tryed to build anyhting from scratch. I've modified some stuff to make it better like getting a transmitter to give better range but that's simple i guess.
10-28-2003 Over year old.
 
 
Angelos
Key Veteran
Location: nr Oxford, OX11, UK

Perhaps I shouldn't have spent the time to make the menu this early in the project and concentrate on the "real" code. But I wanted to make sure that I can comfortably navigate in the menu while the transmitter is calculating data for the next frame. This is performed as an interrupt which reads the sticks and does the maths. I have an additional 2ms delay to compensate for the missing calculations at this point but I don't expect that it will take more than 1 ms for the ARM chip to do the maths. In any case I can navigate though the menu conformably with no notable interruptions.
10-28-2003 Over year old.
 
 
George You
Heliman
Location: West Pacific Island

Hi Mark:
you are familiar with assembly and HDL!
what do you do for a living? Maybe we are in the same walk.
your projest stimulated me to do a survey on the futaba pcm1024 protocol and found only one open result so far, which was posted by the open source forum. If that is 100% correct, then you should be able to use a very small FPGA or a bigger CPLD to decode it. I believe it would be fairly under $5 with Xilinx. Maybe I'll also try to do a decoder for pcm1024 with VHDL, before long...
by the way, the 200 uS thing might be the RF latency I think. I remember there is a 300 uS latency between the pulse trains on the receiver and the transmitter, which is resulted by the comparator in the receiver, not the wave itself. this is true for pcm1024. Maybe Airtronic/Sanwa cut it downto 200 uS and came the insensible claim.
cheers!
10-28-2003 Over year old.
 
 
Angelos
Key Veteran
Location: nr Oxford, OX11, UK

George,
The PCM1024 description at the open source forum is less than 50% complete. Yes you can drive the servos using the absolute values only as they do but that means you are using only every second frame. There are also differential corrections while are mapped to a table which then gives you the corrected positions. Working out the values of this table was the trickiest part for me. If you don't get them right the servos don't move as smooth as with the original Futaba receiver. for example if you values are too small the servo may stop before it reaches the intended position and start moving again when the next absolute frame comes in. as a result the motion looses it's smoothness and will move a bit jittery. Similarly for larger values which will push the servo too far and will then have to come back. You also have failsafe frames, 2 switched channels, battery failsafe on/off and one more bit that never seems to change. Reserved perhaps? I don’t know; but this is the only bit I haven’t figured out. Oh… and don’t forget the frame validation algorithm. Overall, I think that it could be implemented in a FPGA but why? I have put the whole code for the decoder in a PIC micro that costs less than the FPGA.

-Angelos
10-28-2003 Over year old.
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, Folks!

Duranza: There's nothing like going for it to learn! As I mentioned earlier, I like to just do a project to be able to learn about things, and this one's teaching me quite a lot. Don't be afraid to just dive in - it's a blast!

George: I guess it's mostly a function of what you're most comfortable with! My original background was as a firmware engineer, then VP Engineering at several portable PC companies, and these days, I'm a CTO (& VP Engineering). My job is essentially to architect large-scale systems, so I wind up needing to get involved in lots of different disciplines to try to find the right H/W / S/W mix. For what it's worth, the QPSK receiver we're developing at work has a front-end Xilinx for a "channelizer", and then S/W does the rest.

I agree with you that an FPGA could do the receiver job pretty easily for an FSK system. In fact, I'd use Altera, since they are very price-competitive at the low end. For the FQPSK-B scheme, though, there's going to be a ton of math, and that'll put you into a more expensive device category. That's not to say that a H/W solution couldn't be price-competitive, but I prefer S/W for the initial prototyping and exploration phases. Once that's done, if costs are too high, then it can always be retooled in H/W for production volumes. My gut feel on this project, though, is that the S/W solution will wind up as the lowest cost solution for FPQSK-B, as long as the CPU has DMA capability for the A/D converters.

Angelos: The reason you might want to use H/W for the receiver is that the timing constraints we're targeting are quite severe. Nailing timings is trivial in H/W, but much harder in S/W. If you are attempting to develop a truly high-performance solution, and by that I mean both minimum control latency and better R/F performance, it is very challenging to develop something which has no compromises. Specifically, the PCM-FSK solution that I'm working on now is a great example, since I'm trying to do this without DMA or interrupts. In contrast, an FPGA/CPLD would have been far easier.


The Event Compiler

Well, gang, the pursuit of an "ideal" solution continues! I've decided to go with the event compiler approach, and have written a routine that translates an input event list into an executable ARM binary routine in RAM. To make this a tractable problem, I've split up the event handler routine into three chunks. The start of the routine that synchronizes with the H/W timer/counter and sets up registers is pre-assembled normally into FLASH and copied to RAM at runtime, then the event compiler builds the active event code every subframe, and the end of the event routine is also a standard code sequence that's copied from FLASH. By doing this, we significantly simplify the instructions that the compiler needs to know about. In fact, the compiler only "knows" 12 instructions, and one of them is a NOP (No-Operation)!

Why am I doing this? I've realized that with this approach, it should be possible to deliver a solution which has zero jitter, other than that which is inherent in the CPU's PLL! Now, I'd mentioned previously that the CPU's H/W Timer/Counter didn't run fast enough, but I think we can probably make that restriction go away.

[Sorry for the diversion, but I thought I'd explain how we're tackling this one. Since the Philips LPC2104 is so new, there actually isn't a maximum spec yet for the peripheral clock that determines how fast all the CPU peripherals, including the Timer/Counter, run. Instead, there is text in the User Manual thart says that running the clock at the same speed as the CPU can only be done at a speed of less than "XXX"! What's no doubt happening is that Philips is in the process of characterizing how fast all the peripherals run at different voltages and temperature extremes. However, I'm willing to bet that the Timer/Counter, as a very simple component, will easily run at much higher speeds than many of the other peripherals on the chip. Since we don't need those other peripherals, I'm going to ask Philips if they'll bless 1X peripheral clock operation when the only thing that's needed are the Timer/Counter and the GPIOs. My guess is that they'll approve this, since this could get rid of that last source of timing jitter! Not just for my little project, but also for other embedded applications, so it's worth their investing a bit more in testing resources. I'll let you know how they respond!]

The event compiler is a very valuable little trick that is far, far, faster than the standard approach. The worst-case delay between two events is now just 9 CPU clocks, or 150 nanoseconds! And that's the time needed for an input event - the time between output events is just 100 nanoseconds. In general, this routine can handle any number of output events and up to 64 RF sampling events each pass. Fun stuff!

Anyway, now that the event compiler's been written, I'll need to build the rest of the infrastructure to support it, including the event preamble/postamble routines, a code mover, RAM code buffers, etc, and then we'll start testing all over again!

Thanks again for the great support, gang - you definitely motivate me to try to make this as good as I can make it, and I love the challenge!

Have Fun!
MarkF
10-28-2003 Over year old.
HOMEPAGE  
 
 
George You
Heliman
Location: West Pacific Island

Angelos-
yes, you're right. I am just more familiar and comfortable with a PLD.
Too bad the open source is less than 100% correct.
I have an open question here. Why did futaba chose 6B/10B encoding scheme at such a low bit rate? I assume the 6B/10B encoding is designed aiming to embed the clock in the serial data. It is quite reasonable to do this with LAN or Firewire etc. But at a low bit rate like our radio gear, is it really neccessary to do this? For example, UART does not do this but is still very reliable to extract the contents.
10-28-2003 Over year old.
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, Folks!

One more interesting tidbit. I was originally a little concerned that the addition of the event compiler would increase latency, since building the event code obviously takes some time. As it turns out though, we can hide this completely by running the event compiler while we're still in the process of receiving the CRC codes. If it turns out that the CRC is bad, no problem, we just execute a different (i.e. previous) event routine that contains the code from the last good subframe. Consequently, the control latency of this receiver stays where it was: the first servo pulses end as we receive the first sample of the next subframe, or about 30 uS in the case of 6400 bps transmission. Yahoo!

Cheers!
MarkF
10-28-2003 Over year old.
HOMEPAGE  
 
 
Angelos
Key Veteran
Location: nr Oxford, OX11, UK

George,
You are mistaking the 6B/10B with Manchester encoding. Manchester carries the clock the 6B/10B intends to reduce the frequency components of the signal. Look at the entire 6B/10B table… do you see any single 1’s or single 0’s? No…! If you had single 0’s and 1’s then the max frequency of you signal would be twice as high. So with the 6B/10B you can transfer 6bits but in the same spectrum you could transfer only 5 otherwise. Also singe there is a large number of non used combinations (the one that include single 0’s or 1’s) this encoding also serves as a first level of error detection. Imagine that a 10 bit code has 1024 combinations but only 64 of them are used. Thus you can trap a very large number of errors.

-Angelos
10-28-2003 Over year old.
 
 
Angelos
Key Veteran
Location: nr Oxford, OX11, UK

Synthesized frequency

Since I decided to go with PCM1024Z for the time being and to use a Futaba TX module and receiver, I though to investigate a bit more the synthesized TX module. For me synthesized frequency is very desirable.

A quick look inside the TX module revealed an MB1504 chip for the frequency synthesis which is dead easy to control and an X24C01 EEPROM. The EEPROM holds information about the available channels and their frequencies so depending whether the module is 72MHz or 35MHz the TX will display the correct table on the screen. The data below is a dump from 35MHz synth module. Twenty channels in total, start at channel 61 (35.010MHz), end at channel 80 (35.200MHz) in 10KHz frequency steps.

0000: aa 55 23 03 00 14 1b 5a 00 3d 02 3e 04 3f 06 40
0010: 08 41 0a 42 0c 43 0e 44 10 45 12 46 14 47 16 48
0020: 18 49 1a 4a 1c 4b 1e 4c 20 4d 22 4e 24 4f 26 50
0030: 50 1f 54 20 58 21 5c 22 60 23 64 24 68 25 6c 26
0040: 70 27 74 28 78 29 7c 2a 80 2b 84 2c 88 2d 8c 2e
0050: 90 2f 94 30 98 31 9c 32 a0 33 a4 34 a8 35 ac 36
0060: b0 37 b4 38 b8 39 bc 3a c0 3b c4 3c 00 00 00 00
0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I didn’t have the chance to try to decode this yet so I would appreciate any help. It seems that this thread has attracted many electronics and software experts. I don’t know in what format these data are stored. Perhaps they represent the channel frequency or they may be pre-calculated data for the frequency dividers inside the MB1504.

Another very interesting application once this table is decoded is to extend the available channels. My module was purchased quite some time ago when UK had only channels 61 to 80 and thus these are the only available channels to use. Now we have a wider range from channel 55 to channel 90. I am aware that the PPL may not lock outside the preprogrammed band but I intend to try it and also measure the transmitted power at channel 55 and 90 and compare it with the existing channels.

Cheers,
Angelos

Added later:

some observations... I will refer to addresses adding a $ in front of the hex number...

$0000-$0001 is obviously a header to detect that a synth module is present
$0002-$0004 possibly and initial configuration for the PLL
$0005 defines the number of available channels
$0006-$0007 is the start frequency stored as 5KHz steps from DC (0 MHz)
$0008-$002F is Table1
$0030-$006B is Table2

Table1 is formed as byte pairs. The second byte of the pair is the channel number, the first byte shows the deviation of the channel from the start frequency. This again is represented in 5KHz steps.

Teble2 possibly contains data for configuring the PLL. I am working on decoding this. Note this table contains 30 pairs so there is info there for 10 more unused channels. An interesting point this the 10 pairs of 0's at the end. These cover the exact amount of memory space required to add the 10 missing channels on table1.

One question remains… what is on locations $0002-$0004?

I am sure Futaba hates me more and more every day
10-28-2003 Over year old.
 
 
Angelos
Key Veteran
Location: nr Oxford, OX11, UK

Mark,
I was always wondering why Futaba used only 3.33KHz of the channel’s bandwidth but this has now become clear. Decoding the synth module EEPROM I noticed that their intention was to be able have channels at only 5KHz apart. What is your reaction to this? Are you now thinking to stick at 5KHz bandwidth or go for the full 10KHz since it is available. Are there are regulations regarding how much bandwidth can be used by each channel? Perhaps you are limited to 5KHz but there is 10KHz there for safety. Also some clubs (very few) enforce a 20KHz rule for safety which I find unnecessary, but you know… old plankers always need an excuse for their crashes and the most convenient is adjacent channel interference. Not to mention that they greatly dislike my synth TX module.

Cheers,
-Angelos
10-29-2003 Over year old.
 
 
Angelos
Key Veteran
Location: nr Oxford, OX11, UK

I was probably wrong about table 2. I did further test which showed that changing values in tabel 2 does not affect the frequency at all and this was measured with a frequency counter accurate to 10Hz. However changing values in table 1 affected both the frequency shown on the screen and also the transmitted frequency. It is now clear that the 9Z CPU computes the PLL configuration values and they are not stored in table 2.

So what is table 2?.... My new guess is that it contains frequency information for US channels on the 72 MHz band. They are not used but probably they are just left there. These values represent 30 channels starting as channel 31 and ending at channel 60 with 20KHz spacing. Someone in US can you please confirm this? I know US uses channels 11 to 60 but perhaps the synth modules have a limited range. Please let me know.

Added later: Second guess... possibly the original design of the module was for US frequencies covering channels 11 to 60. Then when Futaba converted it to UK freq they wrote over the first 20 channels and left the others unused.

Cheers,
Angelos
10-29-2003 Over year old.
 
 
edgarcat
Heliman
Location: Hackettstown, NJ-US

Hi Angelos:

The synth modul in USA is programed to emit in all the 72MHz channels, from 11 to 60, and yes the first synth modul was in 72MHz, and years later was made the 35MHz version.

Did you know that? When you put the 9Z in PPM mode with the synth modul, the PPM frame is changed, the syncro-pulse is divided in half, one positive pulse and one negative pulse, bots of the same duration, aparently that was made for a timing requirement of the PLL.

I like this tread very much, in special the work that are you doing; go ahead.

Edgar
10-30-2003 Over year old.
 
 
Angelos
Key Veteran
Location: nr Oxford, OX11, UK

Quote 
Did you know that? When you put the 9Z in PPM mode with the synth modul, the PPM frame is changed, the syncro-pulse is divided in half, one positive pulse and one negative pulse, bots of the same duration, aparently that was made for a timing requirement of the PLL.


Thanks Edgar for this. It explains a lot. I guess that the 9Z automatically generates this 'strange' sync when it detects a synth module. This also explains why the G2 interface does not work when the synth module is installed. I'll plug the 9Z on the scope tonight and hopefully I'll learn more about it.

Cheers,
Angelos
10-30-2003 Over year old.
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, Angelos!

Sorry I wasn't able to help out on the decoding of the table - I've been quite tied up in my project (the event compiler is working very well, but I'm chasing a couple of infrastructure bugs at the moment).

As far as bandwidth goes, what the existing manufacturers are doing is being very conservative to reduce costs. The use of so-called "spectral masks" makes adjacent channel interference and intermodulation issues completely predictable. The FCC defines a spectral mask for our channels, so there is no question what will be OK, and what won't be.

The basic problem with FSK is that it is extremely bandwidth inefficient: FSK "splatters" all over the place. To enable cheap filters to be used, manufacturers such as Futaba are lowering the data rate, which increases control latency. There are two ways to improve this situation.

The first method is to go with a more advanced form of modulation, which is what I'll eventually tackle. As I mentioned before, FQPSK is extremely clean - especially with the enhanced form of FQPSK addressed in the article earlier - even without filtering! It flat-out occupies less bandwidth for a given bitrate than almost any other form of modulation. Ignoring perhaps a $15-$20 higher TX+RX bill of materials cost than an FSK equivalent, it's capable of delivering a "free lunch", with a higher data rate, better SNRs, and lower interference, all at once.

FQPSK Rev. B is an example of the second way to improve bandwidth efficiency. Using better filtering can further reduce bandwidth requirements, regardless of the data rate being used - what differentiates Rev. B from the original FQPSK is a more sophisticated filter.

In the days of traditional analog RF design, the tradeoffs that existing manufacturers made were quite reasonable. However, with the advent of SDR [software-defined radio], where most of the processing can be performed in the digital domain, the best answers are often different*!

Have Fun!
MarkF

* For what it's worth, this is exactly why the receiver we are building at work delivers 80 times higher equipment density than current gear, while delivering superior RF performance. SDR may be hard to wrap your head around, but it's worth it!
10-30-2003 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, George!

To add to Angelo’s comments, the fundamental driving force behind coding methods is dealing with the fact that RF is inherently an unreliable medium! If UARTs were as cantankerous as RF is, we’d be using more sophisticated mechanisms to talk to them, too! Umm, now that I mention it, modems are a perfect example of how much work you have to do to build a UART that can handle an unreliable transport! They use trellis coding, adaptive equalization, and a bunch of other tricks just to be able to play UART over a phone line!

In addition to the error-detection capabilities that Angelos mentioned, there are a couple of additional benefits of coding schemes such as 6B/10B that are related to RF design. The first is eliminating DC from the transmitted signal. Many line coding schemes are designed to have an even number of 0s and 1s in each symbol, which has multiple benefits. This improves the purity of the signal as it passes through a (cheap) non-linear amplifier, helping to prevent further splattering (bandwidth increase) in a process known as spectral regrowth. This also helps receiver design, by allowing the receiver’s amplifiers to operate more effectively.

The second benefit of such coding schemes is exploited by Airtronics, among others. Line coding can make it much easier for the receiver to synchronize with the incoming data stream. By preventing certain unique binary patterns from ever appearing in the normal data stream, these patterns can be inserted at the start of each frame to uniquely identify frame boundaries (this is known as a preamble).

Beyond error correction, line coding can have lots of other benefits, too! Their big downside, of course, is that they reduce the actual data throughput significantly.

Cheers!
MarkF
10-31-2003 Over year old.
HOMEPAGE  
 
 
w.pasman
Elite Veteran
Location: Netherlands

MarkF


You have been busy lately! I needed a few hours to update myself of the progress here!

I finally finished my latency measurements on the Futaba system. Some amazing values came out for PCM, check the thread and my report! I still wonder where most of the PCM latency is coming from, transmitter or receiver.

You wrote ( 10-12-2003 04:54 AM)
"the entire process of receiving an RF frame, including input sampling and a software serial->parallel converter, the receiver state machine, receiving the absolute, differential, and switch channels, checking the CRC, building the sorted output list, and actually outputting the servo pulses, takes just 410 uS, and it's written in C! More importantly, that's from the start of the frame, not the end of the frame! "

How is that possible? A PCM frame takes 14.25ms to transmit from start to end, and you can check the CRC only after the frame is received, so how can you get a latency of 410us from the START of the frame?

" With the 8K bps data rate I’m assuming for the PCM-FSK approach, the servo outputs will be updated every 12 mS, or at about 80 Hz. This is already too fast for many, if not most servos. "

Mmmm actually the servos are updated every 14.25ms with Futaba PCM. So I would think they can handle a slightly higher rate of 12ms properly? But of course, low latency requires better servos, everyone will buy these immediately when the next world champion starts using them

I agree that multiprocessor approach would be good idea. But I wonder why to do this with a serial datalink. How about shared memory, that would cause much less latency and more straightforward software updating. Also at some times a fast CPU is better than two slow ones... I have seen several projects with serial-link induced latency problems... On the plus side, a serial cable forces you to properly modularize the work, which can really help development.

"Unfortunately, I haven't yet found a decent dual-conversion solution that runs in this frequency range: the only dual-conversion QPSK stuff I can find is designed for 900 MHz+, so it would be necessary to do this the hard way, with discretes. "

I dont know too much about this, but can't you UNDERclock a 900MHz chip? And is a dual conversion setup so difficult, or is it the combination with QPSK modulatin that makes it difficult?

" Unfortunately, the chip that I'm using doesn't support these kinds of capabilities, so it'll be necessary to go to the Atmel chip to fix it. In the mean time, the question is whether to just publish the code as-is, with the requirement for the dead air, or whether to move on to the Atmel, develop a longer-term solution on that part, and then publish the code. Or maybe do both?"

I would consider the code to be illustrative to the things you didn't explain, but probably not many people are really going to run it. The documentation and explanations here are I think more important, just as the specs and design decisions. To interest a manufacturer, I think you have to show a working system, not just a piece of software...

"This would get so complicated that it’s just not worth the effort. On the other hand, I’m pretty sure that I could incorporate this capability, and still meet the 1 uS loop time, if I were to recode the event handler routine in assembly language."

Be careful not to overestimate the gains from assembly code. Gains up to 3 may be realistic, above that not.

" As far as the heading hold gyros go, I guess we'll find out if they work soon enough! I'll be testing with both the GY401 and the GY601, which I have here. My guess is that they'll work fine, but we'll know in the next week or two! Even if they don't, though, the other benefits of this scheme are important enough that I'll stick with the parallel drive approach."

I' happy with your visionary approach, leave the "it should work now" to the manufacturers If a gyro can't sample the rudder and gain input simultaneously, a simple hack to the gyro to delay the gain input probably can be made. Similar for other old devices.


What I'm still missing is a good evaluation of the modulation scheme. Up to now you stick with Futaba's PCM scheme but is that really the way to go to get the smallest latency? I'm still wondering whether putting more checksums/CRCs/parity bits through the frame could not result in another latency improvement. Like Simprop PCM, but simprop has such a low datarate that most gains are lost in that...



" by the way, the 200 uS thing might be the RF latency I think. I remember there is a 300 uS latency between the pulse trains on the receiver and the transmitter, which is resulted by the comparator in the receiver, not the wave itself. this is true for pcm1024. Maybe Airtronic/Sanwa cut it downto 200 uS and came the insensible claim."

LOL so that redefines latency So what's your latency now, MarkF?
11-01-2003 Over year old.
HOMEPAGE  
 
 
w.pasman
Elite Veteran
Location: Netherlands

Angelos
"The buffer samples and regenerates the pulse with a small delay since futaba pcm produces pulse for channels 1,2 simultaneously. "

Aaaaha this is interesting. I was already thinking they have to do that, because with PCM they drive 8 channels within 14.4ms and every servo can take up to 2ms time. I really have to check out your reverse engineering results


"I'm not sure how I miscommunicated on the overlapping pulse point, but that's exactly what my code does. "
I dont think there was miscommunication. But occasionally something confusing maybe.

"> 6. The protocol CPU calculates the PCM stream on the fly or during the preamble time.
>
Ah, now I see, you are planning on having the transmitter not even know about the RF protocol, which makes sense. In that case, you’ll need to just send all channels once/frame, and the protocol CPU would perform differential encoding, CRC, etc. Sounds like a good plan!"

MarkF, Angelos, this sounds like "protocol CPU" should really be "channel coding CPU"?

Angelos,
Your idea to automatically minimize latency with components sounds nice.
If I understand this right the real problem of modularization here is the synchronizatin to get all data ready just in time. As you sketch it, this is just a serial process (1) getting the pots and calculate the servo targets (2) do the channel coding. If put bluntly serial, you might be better of with 1 fast CPU instead of two slow ones! Or do you want to have (1) and (2) overlap (pipelining)?
Furthermore, what MIGHT be needed for the ultimate low latency is to sample the various potmeters at different times. For instance the throttle (channel 3) is send later than the aileron (channel 1) so it should also be sampled later for lower latency. How does that fit with your approach?
11-01-2003 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, w.pasman!

Congratulations on measuring the Futaba latency! When I make a little more progress on my project, I'll dive into it. For now, though, I'll address your questions below - I suspect most of your questions may have come from skimming the thread a little too quickly!

How is that possible? A PCM frame takes 14.25ms to transmit from start to end, and you can check the CRC only after the frame is received, so how can you get a latency of 410us from the START of the frame?

As I mentioned, this was a measurement of the raw speed of the code, taken by having the event_delay routine immediately return, instead of waiting for the proper event time. This is a good way of measuring total processing requirements in a real-time system (ignoring hot spots, which are dealt with individually).

Mmmm actually the servos are updated every 14.25ms with Futaba PCM. So I would think they can handle a slightly higher rate of 12ms properly?

Let's hope so! We'll see if this is a problem or not soon enough.

I agree that multiprocessor approach would be good idea. But I wonder why to do this with a serial datalink. How about shared memory, that would cause much less latency and more straightforward software updating.

I'm proceeding with a totally one-chip solution, for both the PCM-FSK and PCM-FQPSK solutions. I'll try to support Angelos' dual-chip solution, since that's the way that he would like to develop his system. As far as shared memory goes, there are very few CPUs in this range that support shared memory - you'd need to do some pretty serious ASIC development. Obviously, one CPU offers the lowest latency, so that's what I'm developing.

I dont know too much about this, but can't you UNDERclock a 900MHz chip? And is a dual conversion setup so difficult, or is it the combination with QPSK modulatin that makes it difficult?

No, you can't underclock these RF chips - they are tuned to have resonant frequency ranges for their amplifiers and filters, and they won't work at all at 72 MHz. As far as the difficulty goes, RF design is always complex and time-consuming, and is hard to prototype properly. This is made even more challenging in the software-defined radio environment, due to the need to prevent digital noise from disturbing the sensitive RF sections (I'm familiar with this - we design software-defined radio gear at work). Dual-conversion just adds to the complexity and the layout, by incorporating a whole new set of oscillator spurs that have to be isolated and filtered out. It's one thing when we have a $4M project at work, it's quite another when I'm trying to do this in my basement!

Developing an FQPSK solution dramatically increases the complexity of this development, since we don't just need to add A/D and D/A converters, we need to do some quite complex math to make this work. This is a major project, which is why it took me so long to decide to tackle it to begin with.

I would consider the code to be illustrative to the things you didn't explain, but probably not many people are really going to run it. The documentation and explanations here are I think more important, just as the specs and design decisions. To interest a manufacturer, I think you have to show a working system, not just a piece of software...

I'm sensing some skepticism in your answers, and that's OK - I'll answer it with results, for the code will speak for itself. One of the reasons that this is taking as long as it is is that I am very heavily documenting the code, as I usually do, specifically to help allow other folks to understand how this works.

As I've mentioned repeatedly, I am definitely going to develop both the hardware and the software for this project.

Be careful not to overestimate the gains from assembly code. Gains up to 3 may be realistic, above that not.

I'm sorry, but that is incorrect. I have more than 25 years of assembly language development experience, and have delivered order-of-magnitude improvements on dozens of projects. On this project, the use of assembly language already delivered more than a 10X speedup, even before I wrote the event compiler. By combining this with the event compiler, it's delivering a ~~20X improvement right now (back-to-back events in pure C would be about ~~4 uS, with the event compiler they currently range from 17nS-217nS, based on event type).

What I'm still missing is a good evaluation of the modulation scheme.Up to now you stick with Futaba's PCM scheme but is that really the way to go to get the smallest latency?

No, I'm not using Futaba's scheme at all. I'm currently using my own 16-channel data format, which consists of a preamble, then nine 10-bit words form the data packet. The first word contains the even/odd and failsafe bits, plus eight switch channel bits. The next four words contain the absolute channel values for channels 1-4 during even subframes, and channels 5-8 on odd subframes. The next two words contain dual 5-bit differentially encoded values with exponential coding - they address channels 5-8 during even frames, and channels 1-4 on odd frames. Following those seven words, are two 10-bit CRC check values. There is no interframe gap. The data rate I am running at for the PCM-FSK version is 6,400 bps, and it'll be ~~10K bps for the PCM-FQPSK solution.

I'm still wondering whether putting more checksums/CRCs/parity bits through the frame could not result in another latency improvement. Like Simprop PCM, but simprop has such a low datarate that most gains are lost in that...

Sorry, I can't comment here, since I'm not familiar with Simprop equipment or data format. I am working hard to deliver much higher data rates, though!

So what's your latency now, MarkF?

The current latency is exactly one RF sample delay after the last symbol of the CRC is received. At 6,400 bps, using 5X RF oversampling, the code is running right now with a minimum latency after the end of each subframe of 31.25 uS. Since I'm trying to use the same microsecond PCM step size of today's servos, the maximum latency after the subframe is 1055.25 uS. If I changed to use PCM to communicate with the servos, as I mentioned earlier, the maximum latency would be about 60 uS.

Best Regards!
MarkF
11-01-2003 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, w.pasman!

For emphasis, the times above are the latencies after a frame is received - the worst case in that context is a subframe time plus one RF sample time, or about 14.7 mS until the end of all PCM code 0 servo pulses, for a 16-channel receiver. Remember, too, that all servos are driven simultaneously in my setup, so there is no additional subframe delay as the receiver staggers the servo pulses, as in other systems.

As I'd mentioned in the Airtronics thread, it's definitely possible to change to Hamming codes for error correction, which would remove the frame-based latency, and then you'd have an individual channel latency. In this case, including the time to communicate the channel code and the ECC bits, the worst-case minimum latency from the last sample of a channel would be ~2.2 mS with FSK, or about 1.5 mS with FQPSK. However, the maximum latency would be worse than what I have now (there would be more ECC bits than CRC bits, so the subframe time would be longer).

Cheers!
MarkF
11-01-2003 Over year old.
HOMEPAGE  
 
 
9 pages [ <<    <     3      4     ( 5 )     6      7     NEXT    >> ]13802 viewsPOST REPLY
XHELI.COM . Autography FlightPower . Advantage Hobby

.
.
Radio - Servo - Gyro - Gov - Batt > Starting a Home-Brewed PCM Receiver Project
  UPDATE SCREEN   PRINT TOPIC Advertisers 

Subscribe to This Topic

Thursday, August 28 - 11:55 pm - Copyright © 2000 - 2008 runryder.com | email | link to rr | runryder needs cookie