HobbyKing.com New Products Flash Sale
Reply
Thread Tools
Old Dec 24, 2008, 06:47 AM
Registered User
Joined Oct 2008
140 Posts
hi Olivier,
Quote:
On your firmware page you say that you use the "ack" mode of the cypress to transfer datas between transmitter and receiver. It looks to me that this mode increase the latency time, but I may be wrong.
yes, i guess it does increase latency a tiny bit but only a very small fraction of a servo pulse.
the ack packet only takes the receiver a few us to send out. it is basically a data packet header and CRC.
the Receiver does not monitor whether the Controller receives the ack or not. once the receiver has sent the ack you can access the data register.
i don't think it's an issue but i won't be using this transmission mode in future versions of the firmware any way.
when i finish working on 2 way communication i can get the signal power level from the returning data packet. the return data packet will not be sent until after the servo PWM is updated.
Quote:
I wonder also what happens if a "ack" packet is lost between receiver and transmitter. Is there any retransmitted packet sent by the transmitter, or if there is just a power adjustement by transmitter?
on the Controller i could test for missed ack packets and retransmit but i decided it is better to ignore missed acks and just recalculate and send a new packet.
i think it is better to send a new up-to-date packet than retransmit an old packet.

if the Controller misses an ack then the received power level is going to be very low anyway so the transmit power is automatically increased after enough of them.

Quote:
Regarding the channel switching capability of the Cypress: have you try to switch from one channel to the other continuously ? Do you feel it may work ?
interesting question. i have put some thought into this and have decided how i want to do it but i'm still open to suggestions.
according to the datasheet:
"""25 fast channels are provided with a maximum settling time of 100 μs."""
which means switching channels regularly would be somewhat expensive.

synchronising the change would be difficult.
if the transmitting station sent a command to the receiving station to change channel there would be no guarantee the command got there. in the time it takes one station to switch, realise the other station did not, and switch back 200us have been wasted in settling time alone. not an unworkable time delay but worth avoiding if possible.

an alternative would be have both stations change stations at regular intervals. one of the stations could synchronise it's timing from the first station's.
this method would take a long time to initialise. probably several seconds. if synchronisation was ever lost it would be very difficult to get it to recover gracefully.

my 3rd solution has the most benefits i think.
i eventually want to have 2 RF modules in the Controller, complete with 2 antenna, separated by a small distance. (10-20cm.) the antenna will also be on a different physical plane.
the primary RF module will run communications while the 2ndary module alternates between transmitting on a backup channel and scanning for the quietest channel available.
the current channel number of the 2ndary RF module will be transmitted as part of the data packet on the primary RF module so the receiver knows where to find it if required.
if a better channel is found during the scan the 2ndary RF module switches to that channel.
if more than a defined number of packets are ever lost then the primary and 2ndary modules swap places so the backup channel is put into use.

this method would combine the benefits of channel scanning and would give some resistance to multi-path signal interference which are an issue at 2.4GHz.


dunk.
mrdunk is offline Find More Posts by mrdunk
Reply With Quote
Sign up now
to remove ads between posts
Old Dec 24, 2008, 08:01 AM
Registered User
France
Joined Nov 2003
278 Posts
Quote:
Originally Posted by mrdunk
"""25 fast channels are provided with a maximum settling time of 100 μs."""
which means switching channels regularly would be somewhat expensive.
I can't remember the switching delay for the new Jeti 2.4Ghz system, but it was less than one second. Actually, switch every 100us from channel is not needed.
Based on your ack system, you could consider a switch only if no ack is received by the transmitter for more than X milliseconds. And then on the receiver side, switch to the new channel if nothing received for X millisonds.
This is a bit complex however.
You could also continuously switch from one channel to the other every 10msec. Both sides must switch at the same time to be synchronized. So if one channel is busy, you will not loose anything and keep the same movement accuracy.

Quote:
Originally Posted by mrdunk
i eventually want to have 2 RF modules in the Controller, complete with 2 antenna, separated by a small distance.
What about power consumption? I read more than 300mA for one Unigen module, so it makes 600mA...


Also, I did not find (may be I missed again something) the equivalent of the Panid of the XBee. THis is an identifier which allows two transmitter (or more) to work even if they are using the same channel at the same time.

Is there anything on the Unigen to "sense" power on channels, in order to select the good ones ?
obor is offline Find More Posts by obor
Reply With Quote
Old Dec 24, 2008, 08:31 AM
Registered User
Joined Oct 2008
140 Posts
Quote:
Based on your ack system, you could consider a switch only if no ack is received by the transmitter for more than X milliseconds. And then on the receiver side, switch to the new channel if nothing received for X millisonds.
yes. but how do you know which channel to switch to?
this is why i am thinking about 2 RF modules on the Controller so the spare one can look for an quiet channel.

Quote:
You could also continuously switch from one channel to the other every 10msec. Both sides must switch at the same time to be synchronized. So if one channel is busy, you will not loose anything and keep the same movement accuracy.
this is the 2nd method i described.
it is dangerous because if the Controller and Receiver ever get out of sync they will take a long time to re-sync.
hardware resets do happen. if the receiver was reset by some power issue i think it would take this method too long to start working again.

Quote:
What about power consumption? I read more than 300mA for one Unigen module, so it makes 600mA...
the power draw is only that high while transmitting. i don't actually know it's average draw in my application. i would guess from battery life around 100mA.
the 2nd RF module's primary purpose is to scan for an available channel. as it would be transmitting less often it's power draw would be lower.

Quote:
Also, I did not find (may be I missed again something) the equivalent of the Panid of the XBee. THis is an identifier which allows two transmitter (or more) to work even if they are using the same channel at the same time.
yes. there are 2 ways of doing this.
you can set a hashing key which must match at both ends to get a valid result.
you can also set a 16 bit CRC key that must match at both ends to get a valid result.
i have not done the maths but you could have a lot of these running on one channel without running out of bandwidth.

Quote:
Is there anything on the Unigen to "sense" power on channels, in order to select the good ones ?
yes. there is an RSSI (Received Signal Strength Indicator) built into the chip. if no packet is being transmitted it still tells you the background signal strength.


dunk.
mrdunk is offline Find More Posts by mrdunk
Reply With Quote
Old Dec 24, 2008, 08:57 AM
Registered User
Joined Nov 2008
535 Posts
Quote:
Originally Posted by mrdunk
when i finish working on 2 way communication i can get the signal power level from the returning data packet.
The reciprocal path may give you some idea of prorogation losses, but it can't tell you the signal to noise ratio seen by the receiver. If there's a source of interference that's not visible from the ground (buildings or small hill in the way), the plane could easily fly high enough to be subject to it - so how things look from the transmitter's perspective may not be representative of how they look to the receiver.
Quote:
in the time it takes one station to switch, realise the other station did not, and switch back 200us have been wasted in settling time alone. not an unworkable time delay but worth avoiding if possible.
200 uS is 1/100 of the traditional 50 Hz frame rate. Seems you could improve the frame rate by a factor of 10 and still only loose 1/10 of your available time to this switching?
cstratton is offline Find More Posts by cstratton
Reply With Quote
Old Dec 24, 2008, 10:14 AM
Inciting Riots
village_idiot's Avatar
Joined Dec 2006
9,682 Posts
If you are going to scan for the most quiet channel, you should do this on the receiver end. Consider an airplane way up in the air and all the signals that it can receive, compare to what you might receive on the ground. To do this you could use the low power RF6936 chip as the second receiver, which would also give you spacial diversity if you used it in a remote configuration.

Somehow Spektrum gets 80 channels out of this same Unigen module, and they do indeed run on two channels at the "same" time, so there must be a way of making the oscilator settle more quickly on a channel change. Maybe if you run in unidirectional mode this can be accomplished, so it may not apply to the system you are making.

Also you should make some kind of alarm happen if X number of return packets are missing. This way you know you are getting into trouble and need to bring the vehicle closer or risk a crash. This is something that Jeti did on their new system. You could base it on received signal strength, or on lost packets, or something else, but you should include it and probably with some really loud buzzer/beeper/siren to let you know that things are starting to go sideways.
village_idiot is offline Find More Posts by village_idiot
Reply With Quote
Old Dec 24, 2008, 10:55 AM
Registered User
France
Joined Nov 2003
278 Posts
Quote:
Originally Posted by mrdunk
yes. but how do you know which channel to switch to?
At initialisation, the transmitter simply provide the 2nd channel number to the receiver.
Quote:
Originally Posted by mrdunk
it is dangerous because if the Controller and Receiver ever get out of sync they will take a long time to re-sync.
If you consider using a special byte at the end of the frame that the transmitter add when it is going to switch channel, then the receiver and transmitter can switch almost at the same time. If the receiver for any reason it out of sync, (that can be detected quickly if Tx is continuously transmitting), then it can switch back and forth randomly, I guess the resync in that case should be quick.
Quote:
Originally Posted by mrdunk
hardware resets do happen. if the receiver was reset by some power issue i think it would take this method too long to start working again.
Well, in any case, even with a commercial radio, if your receiver is reset the probability to crash is much higher.


Quote:
Originally Posted by mrdunk
yes. there are 2 ways of doing this.
you can set a hashing key which must match at both ends to get a valid result.
you can also set a 16 bit CRC key that must match at both ends to get a valid result.
i have not done the maths but you could have a lot of these running on one channel without running out of bandwidth.
Hash key or CRC will not protect if you have several same equipments transmitting at the same time, and several receivers receiving signals from serveral transmitter.
obor is offline Find More Posts by obor
Reply With Quote
Old Dec 24, 2008, 10:56 AM
Registered User
Joined Nov 2008
535 Posts
Quote:
Originally Posted by village_idiot
Somehow Spektrum gets 80 channels out of this same Unigen module
Not surprising if you read the data sheet for the cypress chip it contains

Quote:
and they do indeed run on two channels at the "same" time, so there must be a way of making the oscilator settle more quickly on a channel change.
The amounts of time required as reported here are small in terms of the time available.
cstratton is offline Find More Posts by cstratton
Reply With Quote
Old Dec 24, 2008, 11:01 AM
Registered User
Joined Nov 2008
535 Posts
Quote:
Originally Posted by obor
Hash key or CRC will not protect if you have several same equipments transmitting at the same time, and several receivers receiving signals from serveral transmitter.
The duty cycle is not continuous, but intermittent.

Even if the various systems step on each other some of the time, there are easy ways to make sure they don't do it all of the time (for example, randomize the intervals a bit). Having a CRC lets you accept only a packet that hasn't been corrupted. Having a unique CRC seed lets you select only an uncorrupted packet that's intended for you. In the absence of a valid update (on either channel) you hold position, don't get one in too long and you give up and go to failsafes.
cstratton is offline Find More Posts by cstratton
Reply With Quote
Old Dec 26, 2008, 06:07 PM
Registered User
Joined Oct 2008
140 Posts
Quote:
Originally Posted by cstratton
The reciprocal path may give you some idea of prorogation losses, but it can't tell you the signal to noise ratio seen by the receiver. If there's a source of interference that's not visible from the ground (buildings or small hill in the way), the plane could easily fly high enough to be subject to it - so how things look from the transmitter's perspective may not be representative of how they look to the receiver.
hi Cstratton,
i was not being clear. i meant the power level at the receiver can be transmitted back to the controller.
signal to noise ratio is easy to calculate by comparing the signal level after a successful transmission against the power level immediately afterwards.

Quote:
Originally Posted by village_idiot
If you are going to scan for the most quiet channel, you should do this on the receiver end. Consider an airplane way up in the air and all the signals that it can receive, compare to what you might receive on the ground. To do this you could use the low power RF6936 chip as the second receiver, which would also give you spacial diversity if you used it in a remote configuration.
hi VI,
good point. if this was a normal RC system i'd agree.
as i keep pointing out though this is a 2 way system so information from the aircraft to the ground is still important.
if size and cost were not an issue there would be a pair of receivers at both ends.
anyway, i'll know more about the practicalities once i collect some data of power levels from both receivers.

Quote:
Originally Posted by village_idiot
Somehow Spektrum gets 80 channels out of this same Unigen module, and they do indeed run on two channels at the "same" time, so there must be a way of making the oscilator settle more quickly on a channel change. Maybe if you run in unidirectional mode this can be accomplished, so it may not apply to the system you are making.
the CYRF6936 supports 98 channels but only 25 of them settle within 100ns.

Quote:
Originally Posted by obor
At initialisation, the transmitter simply provide the 2nd channel number to the receiver.
hi Obor,
that would break every time a packet went missing.

Quote:
Originally Posted by obor
If you consider using a special byte at the end of the frame that the transmitter add when it is going to switch channel, then the receiver and transmitter can switch almost at the same time. If the receiver for any reason it out of sync, (that can be detected quickly if Tx is continuously transmitting), then it can switch back and forth randomly, I guess the resync in that case should be quick.
yes, this is the method i was talking about.
the problem is you cannot guarantee a packet will arrive.
every time a packet containing the next channel number is lost synchronisation would be lost.
imagine the situation at the edge of the RC system's range where only 10% of packets are getting through. resynchronisation would have to occur 90% of the time channels are changed. resynchronisation in this case would take several hundred transmissions. clearly not practical.

Quote:
Originally Posted by obor
Hash key or CRC will not protect if you have several same equipments transmitting at the same time, and several receivers receiving signals from serveral transmitter.
as Cstratton pointed out,
the unique Hash key and CRC check will only be true if a packet is intended for you.
obviously if 2 transmissions are received at the same power level at the same time there will be a transmission error which is easily detected by the CRC check.

it should be possible to run many of these on the same channel. if there is a collision wait and retransmit.


dunk.
mrdunk is offline Find More Posts by mrdunk
Reply With Quote
Old Dec 27, 2008, 09:40 AM
Registered User
Joined Nov 2008
535 Posts
Quote:
Originally Posted by mrdunk
the problem is you cannot guarantee a packet will arrive.
every time a packet containing the next channel number is lost synchronisation would be lost.
I think the idea is that the second channel number is passed on startup, and the receiver doesn't unlock until it's been received. If you want to do multiple channels, you either send the whole list, or more practically you pick them based on an algorithm that can be independently computed on both ends, and what you transmit is the seed for that.

In terms of rx-tx synchronizing in the hops, I would guess it works by knowing when the next packet is due, regardless if it is or isn't received. Every time a packet is received, the time when it gets through can be used to update the expectation of when the next is due, in order to correct for any clock discrepancies

Obviously that won't work with randomly picking a channel and transmitting it in the previous packet, which is why I suspect they don't do it that way. Spektrum for example seems to pick two channels on startup and stick with them.
cstratton is offline Find More Posts by cstratton
Reply With Quote
Old Dec 27, 2008, 06:10 PM
Registered User
Joined Oct 2008
140 Posts
to be honest, i'm not that keen on the idea of using multiple channels between a single pair of transceivers.
the time delay resynchronising after one station is accidentally reset is in my opinion a worse danger than interference on an individual channel.

this is just my theory for now though. once i am able to gather data from my working system i'll be in a better position to make an educated decision on whether continually changing channels is a benefit or not.

i was just discussing the options.

Quote:
Originally Posted by cstratton
Spektrum for example seems to pick two channels on startup and stick with them.
i do see the benefit of using 2 channels and intend to implement this eventually.
i'm not convinced it is necessary to stick to the same channels once you have 2 radios though.


in other news, was out flying today. the version of the firmware i posted seems to be stable but bare in mind i was flying in a park 1km from the nearest source of wifi or much other 2.4GHz noise.

have not had much time to work on the next firmware version.


dunk.
mrdunk is offline Find More Posts by mrdunk
Reply With Quote
Old Dec 28, 2008, 04:53 AM
Registered User
UK
Joined Aug 2000
1,082 Posts
Hi Dunk, Understanding how the commercial systems works may help consider options. They all have fixed timing and seem to just blast away (once they get started). They use redundant transmissions to compensates for corrupt frames. My observations here http://www.flyelectric.ukgateway.net/24scanner.htm

I think antenna diversity on the Rx is vastly more important than on the Tx. I'm developing a frame loss 'lockout logger' to assess this precisely and I will post my findings.
Regards, David.
David T is offline Find More Posts by David T
Reply With Quote
Old Dec 28, 2008, 05:14 AM
Registered User
UK
Joined Aug 2000
1,082 Posts
I'd like to clarify my antenna diversity comments. The receiving station benefits from diversity. So if you are wanting a robust downlink, then 2 aerials on the tx would help. But you would have to orientate them at 90' to benefit most from that and use them both for receiving data.
dt.
David T is offline Find More Posts by David T
Reply With Quote
Old Dec 28, 2008, 07:36 PM
Registered User
Ron W3FJW's Avatar
Tacoma WA
Joined Feb 2008
561 Posts
For maximun effectiveness you would also need a matching circuit for each antenna, both Tx and Rx. Simply adding a second antenna would halve the impedance creating a mismatch resulting in standing waves which would reduce the effective range.
This may be important but also maybe not. Just something to take into consideration.
Ron W3FJW is offline Find More Posts by Ron W3FJW
Reply With Quote
Old Dec 30, 2008, 03:15 PM
Registered User
Joined Oct 2008
140 Posts
Quote:
Originally Posted by David T
Hi Dunk, Understanding how the commercial systems works may help consider options. They all have fixed timing and seem to just blast away (once they get started). They use redundant transmissions to compensates for corrupt frames. My observations here http://www.flyelectric.ukgateway.net/24scanner.htm
hi David,
thanks for the link. and thanks for taking the time to document your finding.
very interesting reading.
from your page here: http://www.flyelectric.ukgateway.net/24scanner.htm it appears only Futaba are doing anything remotely complicated which would lead me to believe 2.4GHz systems work ok with one channel plus one backup.
i'm surprised to read that many systems do not appear to swap channels if one becomes busy. this would be a very useful feature in busy areas and easy to implement.

Quote:
Originally Posted by David T
I think antenna diversity on the Rx is vastly more important than on the Tx.
yup. i was sticking with my vision of this being a 2 way system so one direction is as important as the other but you guys are starting to talk me into diverse radios at both ends.
originally i was against adding to the size and cost of the aircraft based radio but i think it would add little in the way of size, weight and cost to put the connector for a 2nd radio module on the receiver as well.
i'll write the firmware so it can use a 2nd radio only if it's installed. that way if the user requires cheap and simple they can have that. if they need the greater security of a 2nd active channel they can have that too.

Quote:
Originally Posted by Ron W3FJW
For maximun effectiveness you would also need a matching circuit for each antenna, both Tx and Rx. Simply adding a second antenna would halve the impedance creating a mismatch resulting in standing waves which would reduce the effective range.
hi Ron,
yes, i understand only one antenna can be connected to a single receiver.
i've been talking to one of the guys who i work with who used to specialise in WiFi networks. i believe there are antenna shapes that cut down polarisation issues at the expense of a slight drop in range compared to correctly polarized conventional antenna.
i must talk with him more to see if there are similar solutions for 2.4GHz multipath issues, etc.


i've been thinking about having some PCBs made up to get the size down a bit.
they will have much the same features as the board shown on my website with the addition of a 2nd RF module connector.
any one got a tame PCB manufacturer?
i was thinking maybe these guys: http://www.pcbcart.com/
quite an expensive setup charge but after that anyone who wants one can order fairly cheaply.

i was contemplating running all the microcontroller's unused I/O pins to headers on one edge of the board where they can easily be cut off on the Receiver board but left in place on the Controller.
this way the same board template can be used for Controller and Receiver.
possibly add space for a FT232R on the cutaway section as well so the Controller can be plugged straight into a laptop USB port for data logging.


dunk.
mrdunk is offline Find More Posts by mrdunk
Reply With Quote
Reply


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Discussion Another new 2.4GHz system! Berkie Radios 5253 Today 01:43 PM
Article Blue Ray 450PE Electric RC 3D Helicopter with 2.4GHz Radio System Review Michael Heer Mini Helis 6 Apr 10, 2009 10:28 AM
Discussion DIY 2.4GHz RC project XJet DIY Electronics 22 Jun 23, 2008 03:58 AM