433/315 kit fastest baudrate?

C

ciseco

Senior Member
Hi all,

A question I'm sure 4 or 5 of you will love to answer (probably with different opinions).

As you'll probably know I'm into XBee's. Our home automation protocol is now finished and uses 15.4 strict mode NO ACKS unlike the XBee's maxstream header out the box. This is to allow compatibility with other 15.4 kit (this is to be tested soon). Anyway I digress. We are looking at bringing in 315/433/866 kit into the fold, to add to the TCP/IP/cabled/infra red/wireless 802.15.4 currently supported.

What 433/315 kit is out there that's good?

Does anything support any of these features.

High data rates (very minimum 9600, 115K would be perfect)
Inbuilt error checking (or it'll have to be done in code)
Encryption (nice to have)

Looking forward to having my eyes opened to whats out there.

Cheers

Miles
________
Ducati 999
 
Last edited:
M

manuka

Senior Member
Range needs? Local interference (which can be VERY significant in built up areas)? Nature of your wireless data? Where are you (some countries have tight UHF data regs.) ? Budget -this may run to $$($) for more professional Radiometrix style units ?

In general higher data rates at sub-GHz UHF frequencies will mean reduced ranges. As Forum regulars well know, Dr_A & I have had quite a work out of assorted Asian offerings, with Shenzhen Yishi very satisfactory & cost effective for his rural Australian needs. Many users have found HopeRF units good value as well. Stan.
 

Attachments

Last edited:
C

ciseco

Senior Member
Hi Stan,

Its for general purpose automation so sub 100m would be fine. I've no way of knowing what the local interferance would be in anyone's implementation so I guess we could/should assume the worst. I'm in the UK but we have people using kit all over the place. Budget has to be significantly less (1/3 target) than an XBee. Just looked at radiometrix on farnell and the lowest cost transciever is twice the price so thats it out. RF solutions has something but it's similar in price but it's slower, no enc etc.

Hi Drac,

The yishi thing is rather large to fit into somthing like a light switch, doorbell etc. I see they do thier own switches but dont indicate if its the same protocol etc. 8 channels is useful. The site doesnt indicate the costs. I see the YS-C10U might be available in a 115K version. Still in the same big package though, guess it depends on cost really.

I thought in the past you guys were using really inexpensive modules. Theres 802.15.4 stuff around at ?5 (eg TI & microchip) but these are way beyond a picaxe's capability to drive, as is I suspect an MRF49XA(will be looking at soon I think, the MRF24 has been attempted but proved too much effort)

The hope jobs look better size wise and data (115k), what sort of cost are these stan?


Cheers

Miles
________
BMW M Roadster specifications
 
Last edited:
M

manuka

Senior Member
There are so many offerings (& tradeoffs) that it's akin to giving advise about car purchase! IMHO you'll best "learn by doing". There are many PICAXE based data massaging routines available ( Manchester etc), with some of Hippy's insights probably the best. Do a Forum search- we've been talking about this since 2003!

HopeRF gear ex. works in the US$15 range, but even they have many models. What are you actually doing, & why do you need such high 433 MHz data rates ? I suggest you borrow a UHF scanner to first check this ISM band activity & coverage, perhaps with just cheapie 433 MHz gear (or even a simple £5 wireless doorbell!) Stan
 
Last edited:
M

moxhamj

New Member
Sure, there are also a myriad of low cost ($2) Rx and Tx units as well. They are smaller than Hope/Yishi modules (which are $20-25). Manuka showed some years ago the $2 ones work brilliantly with picaxe. The only catch is that they are deaf. -93db on the Rx (vs -121db for Yishi). And so the ranges quoted are always hopelessly optimistic, eg "100m" ones are actually 10m, and that applies to many different brands.

I like to prove big things work before shrinking it down. I'm sure things can be shrunk if you want to buy in volume and go surface mount on both sides etc. Though the antenna is always going to be bulky at 433Mhz.
 
D

Dippy

Moderator
Maybe CISECO requires fast polling/response times?
Maybe he wants the RF Module to do the data checking/massaging?
Maybe he wants it to behave a bit like an Xbee? (i.e. the RF does all the hard work)

Stan / Drac:-
Out of interest, over a <20m range, in ideal conditions, what is the fastest response time between Host saying "HELLOSLAVE" and getting a response "HELLOMATE" back from Slave with either Yishi or Hope? (using basically a straight PICAXE Serout / Serin). i.e. the total delay and not just bps/number-of-bits.
Sorry, not clear. I mean the total time between:-

Host: Serout"HELLOSLAVE"
Host: Tx --rf--> Rx Slave--Slave:process-->Slave:Tx"HELLOMATE" --rf--> Rx Host
Host: Serin
Host: IF "HELLOMATE"
Host: "Oh it's him".

(With everything set to reliable-flat-out, pedal to the metal).

I've never used either module so I don't know the exact method of 'talking' to these modules or even how either knows EOD from its host(timeout? How long?)
 
M

manuka

Senior Member
Dippy: I've not tried to measure this, as rapid response has never been needed for me with these wireless units. Most of my 433 MHz needs have been pretty pedestrian, and device reading time (especially for the sluggish DS18B20) an issue anyway. Devices may also be sleeping to save power, and some have an internal buffer that first must be filled as well.

FWIW -greater reliability & range (at low tx power) arises with S L O W E R data rates for simple wireless data comms. At 433 MHz I regularly use just 300 bps, but also underclock at times to get even lower.

A fascinating recent QRSS ham radio development has greatly extended this, with rates often below 1 bit per second. Transmitter powers of just milliWatts have been able to span oceans on the HF bands. I'm tinkering with a PICAXE derived sequential multi-tone (SM/T) Hellschreiber beacon at present in fact, using visual decoding via the waterfall display of Spectran. Stan (ZL2APS)
 
Last edited:
D

Dippy

Moderator
Idon't think CISECO is interested in slow, long-range Stan. And we appreciate the business about slow data rates (and types of modulation too). Uncle Myk is big on this.

Maybe CISECO needs to poll a lot of devices sequentially and needs a fast response.
That's how it reads to me. Maybe I got that wrong.

If the RF section is slow then this (and certainly any network) would be pedestrian resulting in tearing hair out.
If the RF can't transport a few dozen bytes in a tenth of a blink of an eye then it may be no use to him.
Something along the lines of performance of an XBee I assume!
i.e. pretty fast.
I think that is the information he is after as opposed to some ancient old bearded Ham wearing turnups diddling away at a byte per week ;)

PS. The TV programme on Mars misssions on BBC recently was interesting - data rates of the old mariners.
Absolutely amazing and not a PIC or a Hope to be seen :)
Ah, real programmers, engineers and mathematicians. Not these modern spoilt brats with all the routines written for them ;)
 
Last edited:
D

Dippy

Moderator
I was just teasing - and include myself. Though there are downsides to always having things done for you/me/us.
Anyway, I didn't mean to go OT so quick. Ooops. Apologies.
 
C

ciseco

Senior Member
Here's a cut and paste of something I wrote a while back, it should explain why a good data rate is required

Why is "real time" important?

Taken from wikipedia here is a definition of how fast we notice things - Simple reaction time is the time required for an observer to respond to the presence of a stimulus. For example, a subject might be asked to press a button as soon as a light or sound appears. Mean RT is approximately 180-200 msec milliseconds to detect visual stimulus, and approximately 140-160 milliseconds to detect an auditory stimulus.

If we look at the statement and think of a simple light switch. If you've used kit like X10 devices over the power lines you'll know what isn't real time in automation, you press the light switch nothing happens, by the time you press it again it might have worked from the first press. A period of around a second is very disconcerting, half a second is very perceptible, we need to aim towards 200ms. In the X10 example this is a one to one relationship, imagine when there's 10's or 100's of messages flying around for different devices. It HAS to be fast for it not to be perceptible. Imagine if turning up the volume was a click............................click........................click affair, I for one wouldn't use such a system.

Making things fast also means making them reasonably small, choosing a fixed length makes timing predictable. This is why there are 12 bytes in a message no more no less. Here's the maths.

A few assumptions

Roughly 70% of all transmissions are sucessful first time on an XBee. This means we need to build in "retries" otherwise it's not going to be very reliable. We normally use 4 retries + the original message. This gives a notional quality of 70%+21%+6.3%+1.89%+0.567% or added together we should achieve 99.757% successful transmissions.

A stock XBee runs at 9600bps, our data packet is 12bytes or 96bits, so we theoretically could transmit 100 messages per second. Remember our retries? they place an average overhead of 42% so the actual number of transmissions we should expect to be possible is nearer 58 a second. This doesnt allow anything for the speed of the reciever or the 3 bytes time XBee waits before commiting a packet, so the actual value will be somewhat lower.

58 a second sounds a lot but it's not if you have 1296 sensors (as aProtocol supports). This is why it's best to run the data interfaces at 115200Kbps as it's good for an estimated 12 x speed or nearly 700 messages a second. Running homebrew equipment at such a high speed isn't always easy. Fortunately the XBee can run at different data rates without too much apparent issue as they actually communicate with each other at a higher 250Kbps and buffer packets, this means we can build homebrew devices that communicate at far lower speeds that will still work.

The actual amount that can be completed sucessfully will also depend on 2.4Ghz interference (WiFi, Microwaves, video senders etc)

You see, we need the data rate to be fast, to appear to be in "real time" all the time. This is why we use the 802.15.4 equipment we do, we need the speed. We do hope in future to offer a different platfrom to XBee but still retain compatibility with the rest of the range through the use of gateways (like we do for IP). This 315/433Mhz kit, this will however have an anticipated throughput in the order of possibly 10's of transmissions a second, therfore only really supporting 10's of devices in real time or the full 1296 if you don't talk to them very often (mathematically any more than every 23 seconds).
________
universal health warehouse
 
Last edited:
C

ciseco

Senior Member
Hehehehe, dippy/manie

I'll reluctantly admit - this brat just wants to get things done, all the tech and maths get's in the ruddy way too often. Link budgets, arrrrrgh I want it all and I want it now!

I guess what we need to do is persuade the worlds governments to allocate a free to use ISM band somewhere low down in the frequencies that's got enough bandwidth to accommodate many 100's of MBps of throughput and for Maxstream to write a tidy little wrapper in a not very convenient size (dig!) as I'd be as happy as a pig in mud :)

Miles
________
uhwh
 
Last edited:
M

moxhamj

New Member
Ah, so you want fast response times so it feels like it is instant. That makes sense. Ok, say you use a bog standard 08M into a Yishi or a Hope module and out at the other end into another 08M. Go for 2400 baud, so you push a button and within about 1ms it would sense that if it was in a tight loop and then sends it out. ?4ms to send it out. Both Yishi and Hope send out in packets and because this is one byte it is less than a packet so there will be a delay of 32ms while it waits for any more bytes. Then maybe 10ms at the other end to process a serin. Total = about 47ms.

There is no need for retries as both Hope and Yishi are extremely reliable and good at rejecting noise as they have onboard microprocessors.

But this does assume only one Tx. If you have more than one unit that might be transmitting, then the problem becomes one of data clashes and it gets a lot more complicated. Instant response assumes a quiet RF band.
 
B

BeanieBots

Moderator
@Doc,
Could that be speeded up by actually sending more (dummy) data to make up a full packet so that there is no waiting at the Rx?
 
hippy

hippy

Ex-Staff (retired)
I'm not entirely sure that time to push a button in response to a visual ( or audible ) cue is the correct way round to measure things as that's not the same as expectation of time taken for a light going on or off after button pushed ( or sound starting and stopping ).

In experiments I've been involved with it does seem that a LED coming on within 200ms of a button push is generally perceived as instantaneous, longer and it is not. That does vary with individuals though, and obviously the quicker the better.

To maintain responsiveness - 'realtime' - it's necessary to get signals from transmitter to receiver in the required time. That comes down to bandwidth and how much data is being transmitted at a time. In most cases it's not necessary nor desirable to have everything transmitting continuously, in many cases simulataneous actions are not that common so if the link is idle it doesn't really matter how long comms takes as long as it's fast enough.

For things like volume controls, it's possible to send just changes but there can be a flood of those at times. The choice is a system which can tolerate the flood without decreasing responsiveness or to accept that other things will be less responsive at those times. Delaying a light switch turn on to facilitate that probably isn't a problem. It all comes down to how likely things are to happen simultaneously which depends on size and type of system. A system for controlling a 1,000 lights in an office block may be easily feasible and acceptable in practice when the same for a 10 channel audio mixing desk may be atrocious.
 
C

ciseco

Senior Member
Hi Hippy,

You are spot on, 200 to 250ms in my mind is the target. If we build worst case and work backwards from a data rate/transit time/error rate we can calculate how many devices we can support without perceived degradation.

Hi Drac,

Ok I'll try and understand, forgive me if I get anything wrong

Let's take 47ms for one transmission for example and lets assume you have 1 light switch and 9 lights, as opposed to just a pair of 08M's as in your example. Mine is a silly example (who needs to turn on 9 lights) I agree but it shows "multiple single" conversations in a really simple way.

Device 1 says to the other 9 in turn, "turn on", we've got 47ms * 9 (nearly half a second before the last turns on). If we assume a network of no more than say 10 devices and a worst case response time of around half a second then your example is up to the job.

IF however as you elude to, needing to work within a "quiet band" and "the problem becomes one of data clashes " then that?s just not feasible in the real world especially at 433 which is rather busy in urban areas. There we must agree? So we need to build in some redundancy or the network will be unreliable.

Lets start by assuming that you are right that "data in" always appears as "data out". We first need to know that all 9 lights did actually turn on so we need acknowledgements. Oh the down side is we have just increased the traffic by 2 so the number of devices we "can" talk to in half a second(our target) is halved to 5. Or we need to go twice as fast to compensate 4800 bps. So with perfect transmission and no data clashes 2400bps will support 5 devices at a guaranteed maximum latency of about half a second.

Then lets try this for real with 2 light switches and 8 lights. What happens when both switches are pressed simultaneously, we see data clashes thus lost data. We then have to account for this happening and retransmit. We could retransmit forever but this would be unwise (it would avalanche at some point) so we need to weigh up reliability with extra bandwidth being expended on acknowledgements and retries.

I have no idea how well either of those boards cope with such a situation it would have to be tried and a successful receive rate determined. This is where XBee achieves around 70% (confirmed by hippy quite some time ago). If we wanted 99.75% reliability we'd need 4 retries. This places a 42% overhead in comms. Oh we now need in theory 6816Bps to support 10 devices.

The overall outcome is sort of what I expected, a 433 data network at 9600 could only be expected to deliver a guaranteed minimum latency within 1/4 sec to perhaps 10 devices.

Lets see how quick we work instead (because I've never worked it out this way round, only ever top down)

at 115200 bps, it takes

0.833ms to send 12 bytes
0.208ms to wait 3 bytes for XBee to confirm the packet
10ms to process the serin (assuming your figures)

we have 11ms as opposed to 47ms with the majority being the rather slow serin. This is why we prefer to run data interfaces and micros a lot faster (min spec 28x1), this is then in the order of just a few ms (i'lll take 5ms for easy maths). Even at this speed the guaranteed amount of data arriving at the other end within 1/4 second after acknowledgements and retries is only in the order of 140 (200-42%)

Does any of that make any sense?

Miles
________
Ford Model TT
 
Last edited:
hippy

hippy

Ex-Staff (retired)
All makes sense, and it also highlights the issues with wireless devices which need to handle collisions, data being lost or corrupted, acknowledgements and re-sends. All this happening unpredictably, randomly and asynchronously is what makes things so hard, even to get one's head around what's going on at any point in time.

The complexity of that is what has kept such systems from the market in the past, and why most now are using ZigBee and similar which handle 'guaranteed transmission' themselves. Such products have whole teams dedicated to making it all work as it should which otherwise has to be done by developers in their own code. Single point-to-point is fairly easy, multi-point at least a magnitude more difficult.
 
C

ciseco

Senior Member
Tell me about it, been a big uphill journey for me/us. Taken 3 odd years, the summit has been reached though and the lowly XBee has helped tremendously. Although we also support IR and TCP/IP, I've hardly ever waivered from Maxstream's kit (dont mention the MRF24!), ok it has it's problems, not least size, expense and a ruddy power consumption like blackpool when the lights are on.

Coming up with ways of guaranteeing throughput, reception, sleep states etc and wrangling with multimillisecond retries has been a pain in the rear to say the least, nothing is perfect, compromises made, not least having no routing/meshing (which actually arent always a good things anyway). That's wireless for ya! An ISM band lowdown with big bandwith (100's MBps) would be perfect. Till then nothing ticks all the boxes I have :(

On a better note!

This all started with the picaxe + some rev ed xbee boards, have to offer clive a pat on the back, the man did good! I hear you know him hippy, would you pass on my thoughts?

Sadly I don't spend much time in the forum anymore. Our code runs on so many different platforms I dont get much chance to come back. Currently porting to arduino as I type, syntax is a pain! much prefer a flavour of BASIC being back here seems homely and familiar.

I guess my suspicions were right that there wouldn't be much easily available at 433 that was suitable for many 10's to 100's of devices, thats a big shame.

I guess until we get nitty with the likes of the MRF49 jobbie and the like it'll remain just a dream. Oh well, was worth the question.

Thanks guys for your input
________
marijuana vaporizers
 
Last edited:
M

manuka

Senior Member
ciseco: Thanks for your now clearer need insights, which Hippy/Dr_A et.al have nicely "enlightened" upon. Spectrum slots are exceedingly valuable- recall tenders earlier this decade that had billions thrown at them - so forget "lo down" UHF bandwidth suddenly being made freely available.

The 433.92 MHz ISM slot actually spans ~1½ MHz, so spread spectrum type devices may have appeal. Have you hence checked MicroChip's new MRF49XA FHSS (Freq. Hopping Spread Spectrum) wireless offering? SiLab make something similar. These darlings are fast, powerful, sensitive and CHEAP (~US$3), but setup looks not for the faint hearted. Their data sheets run to 102 pages,although Microchip's shorter application note is quite lucid. A man of your calibre should have no problems with them however, & although essentially educationally motivated, I'm keen to give them a workout myself!

THOUGHT: Perhaps also consider sub-GHz at higher ~900 MHz freqs.? Even the likes of HopeRF make cheap gear for this wider slot, but (when compared with 433 MHz's freedom) your local regs. may limit applications.
 

Attachments

Last edited:
C

ciseco

Senior Member
I've had a little chat here, when things are a little quieter we might have a bash at the 49. If it didnt take too long or I got help from outside I'd certainly publish circuits / code as part of our sister open source project


Miles
________
YZF-R7
 
Last edited:
D

Dippy

Moderator
Beer obsession.
Do you want user-settable variable sized packets?

I'm not saying it's not PICAXEable. But it's whole lot easier in a.n.other language if you seee what I mean.
 
M

manuka

Senior Member
Dippy: "First Draft/Draught"? I'll certainly have one if you're shouting-& a packet of chips too.

Although it looks PICAXABLE, a bare "49" (& it's equivalents) are still too recent & sophisticated for the skills & resources of most small users, so any insights you offer would be MOST welcome I'd say.
My style with the likes of these offerings is to first make in depth investigations -much as I did in 2002 when attempting to locate a decent friendly & cheap microcontroller! Stan.
 
D

Dippy

Moderator
I'll let you into a secret Stan. Just between you and me...
What I do is contact Microchip, let their technical department (and a 3rd Party tester) do the 'in depth' investigation :)
Then they tell me all about it, and give me advice on component types, sizes, spacing, ground plane coverage and gaps. And ALL the other things not included in the Data Sheet - including preliminary test performance. It is quite impressive for a tiddler.

MRF49 , as you can imagine Stan but others probably can't, is not really breadboardable - calling all novices, don't do it.
It has to be on a d/s or 4 layer board with everything correctly specified and positioned.
I'll be doing the code in another language.

If it all works (and really it is simply an evaluation that I'm doing with a half dozen prototypes) then I'll PM you the control part of the code and then you can see if it can be PICAXEd. I'm pretty certain it can be.

On the other hand, I found the MRF24J awkward and the first Data Sheet had errors. A few days later (it seemed like weeks) Microchip released a second data sheet - twice the size and with major changes esp register names. It was a nightmare. And I would say that the 24J is not to be taken lightly as far as comms and control is concerned - though actual module is far more 'pleasing' than XBee (which, these days, is a little pricey, but very good).
I would certainly say that the MRF24 is well beyond 99.99% of PICAXErs.
 
M

manuka

Senior Member
Dippy: I like your style on this, & will eagerly await developments- as no doubt will many others! Stan.
 
You must log in or register to reply here.
Top