Just an idea...what if we would modify the Hubsan TX to a module which could be attached to the back of FlySky TX as an additional TX module?

what kind of signal would you send to this new attachment? where would it come from in the 9x? where would it go to in the hubsan board?

9x only has ppm out. hubsan board has no control inputs at all. it would be great if these "universal" radio options actually used a universal interface like ppm instead of the really queer spi.

PPM is basically an analog protocol. It defines a specific set of actions to be taken (servo movement) and the receiver will virtually never come up with exactly the same input as the transmitter outputs. SPI is just an interface. It defines a digital way to communicate any binary data between a master and slave device. They aren't really comparable.

All of the modules I've been working with are simply RF transceivers, they have no knowledge of the meaning of the data they are transmitting, and so can't take PPM as an input.

A 'univeral' module that worked only with PPM would need some secondary input (either a dial, buttons, or some other 'trick' like power-up with inputs set in a specific configuration) to communicate additional information. It may be a necessity, but it isn't an ideal situation.

Personally, I think PPM is a terrible protocol. In the days of analog transmitters and primitive microcontrollers, it made sense, but these days, an all digital system would make more sense. But we've got what we've got, so we need to make do.

And yes I know the PPM signals are digital, but the information is transmitted as a pulse-width which must be sampled and is thus dependent on the sampling rate and so will have inherent sampling error.

Originally Posted by PhracturedBlue

PPM is basically an analog protocol.

Originally Posted by PhracturedBlue

And yes I know the PPM signals are digital

make up your mind!

you probably mean ppm, contrary to its 0-5v or whatever nature, is in the analog domain. very few realize this. as such is theoretically prone to offsets and noise. but in a practical sense works quite well as evidenced by the millions of radios depending on it in the past, present, and future. one thing it definitely has going for it is standardization. fortunately the many attempts to mutate and bastardize had limited success. im not a huge fan either but it is what it is: the best way for "most" radios to communicate with "most" modules. the alternative is chaos, frustration, and disappointment.

btw i dont understand your comments about needing dials or buttons. 1ms is 1ms. 2ms is 2ms. or close enough to work for most applications. any offsets can be accounted for in the radio settings. or am i missing something? (wouldnt be the first time)

ps as far as sampling error, in this age of 10bit/12bit 1us adc that really dont seem to be a factor. servos with any dead band at all and certainly motors will not have issues with 0.1% jitter. its often claimed even 5 bit (3%) is acceptable for most rc applications.

Originally Posted by dave1993

btw i dont understand your comments about needing dials or buttons. 1ms is 1ms. 2ms is 2ms. or close enough to work for most applications. any offsets can be accounted for in the radio settings. or am i missing something? (wouldnt be the first time)

Sorry, I was discussing converting PPM to the relevant protocol commands for 2.4GHz transmission, since the actual transceivers don't speak PPM?(specifically the ability to change protocols or options)

I agree with everything else you said.

I am currently trying to build a usb interface using a A7105 so that the Hubsan x4 can be controlled by a computer. I don't know if it would be possible to control more than one at the same time.

If this is possible I would like to use a Kinect to monitor position and feed back as commands to correct position

It should be possible, although binding will be a little tricky. you'll need to bind the 1st with the 2nd off and then bind the 2nd afterwards. After binding is achieved, thee shouldn't be any issue running multiple quads concurrently as there is lots of time between packets.

Subscribed!

PhracturedBlue, just to add my thanks to you and the others you mentioned on the deviation site for working on this. Without deviation we mode 4 stick flyers wouldn't have that choice in fun that we do now.

Next one for me to fly my deviation would be the x4

I have carried out a dump of the Transmitter but there are some differences to the information posted previously

Packet 6-10 different
packet[6] = 0x97;Not 0x08;
packet[7] = 0x53;Not 0xe4; //???
packet[8] = 0xb5;Not 0xea;
packet[9] = 0x62;Not 0x9e;
packet[10] = 0x1c;Not 0x50;

Originally Posted by Gageteer

I have carried out a dump of the Transmitter but there are some differences to the information posted previously

Packet 6-10 different
packet[6] = 0x97;Not 0x08;
packet[7] = 0x53;Not 0xe4; //???
packet[8] = 0xb5;Not 0xea;
packet[9] = 0x62;Not 0x9e;
packet[10] = 0x1c;Not 0x50;

Thanks. It is useful to know it is Tx specific, but that doesn't help much about what it is for. Maybe it is an additional piece to identify the Tx. , though 9 bytes of info for Tx identification does not make much sense to me.

I should probably play with changing these values to see if they affect binding in any way. I don't recall if I ever fiddled with that or not

I'm in for a read on this one, someday I'll be smart enough to contribute, oh gadgeteer, I love the USB interface an Kinnect auto pilot idea.

Has anyone seen how they used the Kinnect in the paranormal activity 4 movie?

Originally Posted by PhracturedBlue

Thanks. It is useful to know it is Tx specific, but that doesn't help much about what it is for. Maybe it is an additional piece to identify the Tx. , though 9 bytes of info for Tx identification does not make much sense to me.

I should probably play with changing these values to see if they affect binding in any way. I don't recall if I ever fiddled with that or not

I don't think they make any differences I have changed back to your original numbers. The biggest problem that I am having is the timing of the binding. Using a USB interface latency is a problem as soon as the packet is transmitter the A7105 needs to be setup to receive otherwise it is missed. I can normally get the first three binding packets then the rest are lost.

Just dumping this in here
Parent quad has chip and linked to rc hand held controler
Parent sends out varibles simiular to its flight path and is refreshed 1 sec
Parent sends out that flight path other quads along with changes that macth a varible set on xyz
Xyz varibles received and flies to that
In other words why not fly one quad and have it send out a beacon to other quads that would receive it.just change the xyz value according to the fly rates....this quad drops 1 foot at this throttle so b
Eacon out a code to make it jump up a foot to follow the becaon quad that already flew that path.


Beacon quad tracks its flight while feceiver quads only receive code transmitted by the becaon quad that are recorded as you fly,.........um well maybe thats a idea for someone maybe not

It seems the goal is to mimic the protocol that is in the original hubsan controller.
But how about turning the original controller into a glorified RF module?
Finding where the PPM stream is, cutting its PCB path and injecting the PPM of my own "big boy" transmitter.
I hate thumb controllers, Id much rather enjoy "pinching" my own familiar pult transmitter sticks.

Originally Posted by Freakazoid

It seems the goal is to mimic the protocol that is in the original hubsan controller.
But how about turning the original controller into a glorified RF module?
Finding where the PPM stream is, cutting its PCB path and injecting the PPM of my own "big boy" transmitter.
I hate thumb controllers, Id much rather enjoy "pinching" my own familiar pult transmitter sticks.

I don't think there is any PPM anywhere in the original Hubsan Tx. it directly speaks SPI as far as I know.