28 replies to this topic

[Pip]

I have the modem transmitting it's 1st transmission tonite

It's currently on 433.92MHz (ignore the frequency readout in the video as the digital receiver is operating in under-sampling mode), transmitting a constant random sequence of bytes at 9.6kBytes/Sec, Tx set to 1mw (it does various output levels from 1mW upto 100mW but 1mW is fine for testing), -113dBm estimated receive sensitivity in 9.6kbps mode (untested), modulation mode is GFSK.

I have set up various bandwidth modes it can operate at from 1kbps (best sensitivity) upto 256kbps (highest data-rate thru-put).

The carrier is very clean, very pleased.

Spectrum analysis

Attached Images

• 

[OlivierD.]

Hip Pip Pip....... Hooray! Congrats! 

What do you figure the range is going to be @ 256kbps? Nice to see this thing moving forward so fast.

Regards,

[Pip]

Well, it's hard to say really, it depends on the enviroment you use them in.

The receivers estimated sensitivity (for BER = -1e3) in 256kbps mode is -100dBm.

In theory (totally untested), with line-of-sight, Tx set to 100mW on the 434MHz band, with 0dB gain
antenna's, dry soil it can be 'upto' 9kM (unlikely though in the real world).

But with wet soil (been raining or whatever) it can fall to 390 meters (I didunt realise wet/dry soil
made such a difference).

It really depends on a lot of things really, antenna orientations, trees, buildings, interference, etc.

Once I have them talking to each other, we will do some range testing, as these modems have yet to be
tested for that, it's still kinda experimental.

What I may do is to get the modems to auto step down in bandwidth/bit-rate to increase the range (receivers
have increased sensitivity at slower bit-rates) if they loose contact with each other or the link quality falls
to low, then step back up in bandwidth/bit-rate when the link quality improves, just to try to maintain a usable
link ... this is assuming that a slower bit-rate link is better than none at all.

I could also implement the UAVTalk protocol within the modem firmware. That would give the modem the ability to
monitor the type of data the OP system is talking with and make decisions on which UAVTalk packets are unimportant
and drop them if required, to allow the most important UAVTalk packets to get thru ok - ie, uav movement control
packets and lat/lon/height/velocity/attitude data.

These kind of things are totally do-able when we have our own modem firmwares (rather than ready made RF modems).

[Pip]

Here's another video for the RF minded peeps.

This time the modem is set too 32kbps mode.

The video stutters because of the screen recording software

32kbps GFSK transmission spectrum

[CheBuzz]

Implementing UAVTalk would open up so many possibilities! Besides what you have mentioned, which would be an amazingly useful feature, you could know which address the packet was destined for when multi-platform control is implemented. This would allow you to direct that packet at the intended receiver instead of just broadcasting, similar to API mode in commercial receivers.

I imagine their are much more benefits to including it, so count one vote from me for implementing UAVTalk in the modem firmware.

[peabody124]

Awesome work Pip! Great to see it getting so close.

Pip, on 02 September 2010 - 08:54 PM, said:

What I may do is to get the modems to auto step down in bandwidth/bit-rate to increase the range (receivers
have increased sensitivity at slower bit-rates) if they loose contact with each other or the link quality falls
to low, then step back up in bandwidth/bit-rate when the link quality improves, just to try to maintain a usable
link ... this is assuming that a slower bit-rate link is better than none at all.

That sounds like a great feature.

Pip, on 02 September 2010 - 08:54 PM, said:

I could also implement the UAVTalk protocol within the modem firmware. That would give the modem the ability to
monitor the type of data the OP system is talking with and make decisions on which UAVTalk packets are unimportant
and drop them if required, to allow the most important UAVTalk packets to get thru ok - ie, uav movement control
packets and lat/lon/height/velocity/attitude data.

I would thinking the message throttling/prioritization is better done on OP that is generating them and knows more why it's sending certain packets. However, I think the idea of there being feedback in that sense is a really good one. Either the modem could insert a UAVTalk packet in the RX stream that would change the bandwidth settings on OP or just have in API mode a way for OP to monitor link strength (which would be ideal since it would generalize for people that still have XBee around if someone implements their API mode). Also keep in mind object ID's/field can change everytime we change something in flight - that would require many more updates on the mdoem and places for mistakes. Then the modem might start suddenly dropping the important packets by mistake because they are unknown.

[Pip]

Well I can certainly get the modem to create a UAVTalk packet which contains the signal strength (not always a good indicator) and a link quality value (the best one to use), plus anyother information that might be desired about the link (how full the modems data buffers are with queued data etc).

If I do implement UAVTalk (I'd like too for the API mode) then you'll just have to settle on fixed packet ID's won't you, and not change em .. then if you want new/different packets then use new ID's for them?

We really ort to have a way for the modem to let the GCS (and UAV) know if the link is not so good anyway, because if we don't then the circular TX data buffers in the modem will become full with data waiting to be sent to the other end if the link fails or becomes too unreliable. UAVTalk (the modems API mode) would be a good choice for that I think.

It'll be a while before I get that far anyway so don't worry.

Yes chebuzz, I could get the modem to talk to more than one uav at a time (not a problem) if the GCS includes UAV destination ID's. I'm using the STM32's built-in serial number to identify each modem (every modem needs it's own unique serial number) for pairing anyway, so I don't see a problem with that. Just means you have to share the available RF channel bandwidth between each of the UAV's on air at the time, but I don't expect that would be a problem really.

[peabody124]

Pip, on 03 September 2010 - 01:08 PM, said:

If I do implement UAVTalk (I'd like too for the API mode) then you'll just have to settle on fixed packet ID's won't you, and not change em .. then if you want new/different packets then use new ID's for them?

Fair point but if we realize something needs a new fields or whatever...

Pip, on 03 September 2010 - 01:08 PM, said:

We really ort to have a way for the modem to let the GCS (and UAV) know if the link is not so good anyway, because if we don't then the circular TX data buffers in the modem will become full with data waiting to be sent to the other end if the link fails or becomes too unreliable. UAVTalk (the modems API mode) would be a good choice for that I think.

It will also want to be reconciled with the GCS/Flight stats too since they try and monitor the link quality through that. Probably no point in onioning CRC's either.

[Bani Greyling]

If the UAVTalk messages have priorities in them, then you could let the firmware send some messages eagerly and some lazily (or drop them if they are below a certain priority)

[peabody124]

I know there is a priority task in the Telemetry Module, but I'm not familiar with what gets routed through it. I know I run my link pretty congested and some of the periodic updates get dropped. We definitely need some work on the bandwidth control as well.

[Pip]

The idea about including a packet priority value (a single byte say) in the UAVTalk packets (in the header) sounds
like a good idea to me for the modem firmware to decide which are the important packets that need to get through. Then the
modem firmware doesn't need to know the contents or the format of the rest of the packet, the packet format after the
header can change as you see fit. If you have a fixed header format for the packet your fine.

If you arrange the packet ID's in order of priority, ie packet type/ID '1' has higher priority than say packet
ID/type '3', you then don't even need to add a priority level byte, you get a priority level indication for
free (no extra bytes needed).

[peabody124]

It would probably need to be another field since the id's are essentially a hash right now to make sure they don't get used if the fields change. Also that would avoid unnecessary PipBee firmware upgrades.

I'd still like to lay out the pro's and con's of doing the prioritization on the mainboard versus the modem though. It seems more sensible to me just to not push packets to the modem that are going to have a hard time being sent.

[Pip]

Yes sure James, it is a good idea I agree to have the GCS (and the UAV main board) drop the unimportant UAVTalk packets when the link is struggling. I'm easy with whatever people decide.

Having this option (in either the GCS or the modem) does allow for the modem to fall back to a lower RF bit-rate when required, and in doing so maintain a link at somewhat longer ranges than would be possible with the higher bit-rates.

I'll let you know the real-world range differences when we are able to do some range testing at all the difference RF bit-rate settings.

In theory the line of sight range you'd get at say 2kbps (rx sensitivity -117dBm) is 4 times the line of sight range you'd get at 256kbps (rx sensitivity -100dBm) with using the same tx output power for both bit-rates. So if you get say 1km at 256kbps, you'd get 4km at 2kbps. The same applies to all types of radio systems, not just little RF data modems.

Anyway, that's not important right now, we have to get flying first, and then work on improvements.

[peabody124]

Oh, I totally agree with the modem throttling the bit rate dynamically - sounds like a really good idea. I'm just debating if the best implementation is the modem to do filtering, or to somehow inform gcs/flight to send less stuff.

Right now I'm finding both HID and RF telemetry saturate at around the same rate so the link isn't the limiting factor (although when flying today I lost telemetry at a pretty short distance - albeit on my cracked modem - at 50m !!!).

[davey]

i'm not convinced that USB is best for real time communications although easy to Implement , due to the latencey of the usb specs etc ( it is suprisingly weak here and not guaranteed , as i have found out in other real time applications ) , and that although due to a mixture of protocols etc over usb , serial and radio , their comes a point where one interferes with the other , coupled along with windows non realtime OS , this is of course an area where posix type OS wins , perhaps as a point of discussion rather than outright theory , we look at a radio link directly to Ethernet as an option , and reducing the conversions especialy on simplex serial links .

i'd feel the saturation bottleneck is more at the GCS and control station rather than the flight systems .
and probably more noticeable under windows and may also be more noticable using QT than a true windows app , this of course is a trade off subject for a cross platform app

Yes Pip , i'd agree with you that having a Packet id priority and UAVTalk protocol should help vastly in this

Just Thoughts etc

[peabody124]

Good point, I maybe I'll try disabling all unnecessary plugins and see what speed I can get...

[CheBuzz]

The problem I see with throttling packets on the main board is that it may then begin dropping packets when there is still bandwidth available. The modem would need to be able to communicate to the main board when it is sending too much data, as has been stated. But this then limits the auto-scaling to the pipXtreme as commercial data modems won't be sending such information.

The only true advantage I could see is if CPU time becomes a limited resource on the main board, having throttling logic on the modem would free up some CPU cycles, though I imagine the difference wouldn't be all that much.

Also, I second the notion of implementing a link quality message.

[peabody124]

CheBuzz, on 05 September 2010 - 05:48 PM, said:

The problem I see with throttling packets on the main board is that it may then begin dropping packets when there is still bandwidth available. The modem would need to be able to communicate to the main board when it is sending too much data, as has been stated.

I'm not sure that's entirely true. In either case the modem is measuring link quality based on TX errors (I assume that's the metric you're using Pip?). At that point it's simply _who_ decides what to send. It just strikes me that the main board has more context to determine this.

Quote

But this then limits the auto-scaling to the pipXtreme as commercial data modems won't be sending such information.

I bet something is available from XBee when in API mode - but that would require having PIOS_COM know something about that which will need to be implemented cleanly. The PipXtreme only option would be to inject a fake UAVObject into the stream and pretend it comes from GCS. I sort of like that anyway - it's not unreasonable that more advanced features like automatic packet throttling be available on more advanced hardware... The object could be sent both ways too so GCS and Flight both know about it.

Quote

The only true advantage I could see is if CPU time becomes a limited resource on the main board, having throttling logic on the modem would free up some CPU cycles, though I imagine the difference wouldn't be all that much.

Well I think the OP context is another advantage, as well as whenever OP firmware changes the PipXtreme firmware doesn't have to.

Quote

Also, I second the notion of implementing a link quality message.

As a UAVObject or as something else in the serial data? The later would be trickier but open up XBee API mode and thus more support. This is redundant with my previous point, but right now PIOS_COM is used as a HAL that sends through multiple paths (debug uarts, HID, modem...). I suppose we could make another target be "XBee API on port 0", "PipXtreme API mode on port 0", etc. However it opens up a can of worms if you get that setting wrong then have to fall back to USB to save the right value to SD, etc...

Just requires some thought if not a UAVObject. That, I don't see any problem as long as Pip is UAV aware. Detail: UAVTalk doesn't specify a data size, so this means Pip would either 1) need to be updated whenever objects change - ick 2) frame on a set of rarely changing objects and insert after them 3) modify UAVTalk to include a size field. I'm personally in favor of the later. I add it by hand in the logging right now because you need that to deal with any incompatible objects.

[stac]

I haven't seen a schematic for the radio so I have no idea how full-featured the hardware interface is so apologies if my comments make no sense.

What about a simple CTS (and maybe RTS) signal.That's consistent with hardware flow control on a typical serial link and it removes any of the uavtalk details from the modem. This would also be able to use the back pressure from the modem to trigger QoS aware discard on the OP main board.

As peabody said, the main board has the best context for deciding which messages to discard. I'd say we would only want to make the radio aware of the uavtalk protocol if absolutely necessary.

For link-quality messages, you really only have two main ways to implement it. Either in-band (like the proposed use of uavtalk messages) or out-of-band which requires something like HDLC byte-stuffing to create the out-of-band channel. Having the modem know uavtalk has a number of issues already listed by others. Using byte-stuffing requires processing on the modem and on the OP main board to stuff/unstuff.

[osnwt]

stac, on 06 September 2010 - 02:27 AM, said:

What about a simple CTS (and maybe RTS) signal.

According to the image at this page, CTS/RTS signals are available from modem. But they are used for AF at mainboard, though...