I am aware of the limitation but would like to know why and if there is a way around it? Thanks.
Why the 26 nodes limit?
(22 posts) (8 voices)-
Posted 22/07/2010 12:37:30
-
I'm no rf12 expert but since JC is on holiday I'll give my 2 cents:
First of all: the concept of node id's is something JC's RF12 lib creates. You could make your own rf12 lib which allows for more node id's. But the easier way would be for you to just add your own bigger "node id's" in the first byte(s) of your payload;-) Not exactly the same but probably sufficient for some scenarios.
In contrast, the groupid is something which is implemented by the RF12 chip itself.
JC designed the packets in his RF12 lib to have 1 header byte, 1 length byte, then payload and followed by 2 CRC bytes. The header consists of 3 protocol bits and 5 node id bits. In 5 bits you can but 32 possible values:
0 is reserved for broadcast
1..26 are suggested for normal nodes
27..30 are suggested for special nodes (but nothing prevents you from using it the way you like, expect for perhaps future incompatibilities if JC decides to do something with those)
31 seems reserved? (although I cannot see the rf12 code do something special in that case)
Posted 22/07/2010 13:13:48 -
As stef007 suggests, the easiest thing to do is to make your own 'node id' as the first byte / word of the payload.
The RF12 lets the user define their own sync byte to signal valid transmissions. JC has cleverly used this as a way of implementing groups. The downside is that a node can't listen across groups as it's hardware sync.
Personally I'd be very pro a v2 rf12 library that addresses the following. This would be incompatible with current JeeNodes, but they can be easily reprogrammed. If firmware version was printed out over serial at power up, that would make it even easier.
1 byte source address (it's currently either / or)
1 byte destination address (it's currently either / or) //node can use one or both. destination chooses to accept messages for it or ones for it from a specific address
group byte as separate byte or otherwise omit (lets units communicate across groups if wanted)
Posted 22/07/2010 15:56:26 -
Oh I see. I think 1 byte each is a sensible choice. I am just starting with PIC programming but I'll see if I can manage to modify rf12 to do that. Thanks!
Posted 23/07/2010 19:58:25 -
@edwardhorsford wrote: > The downside is that a node can't listen across groups as it's hardware sync.
Ah, but it can, with a little trick: put the RFM12B in 1-byte sync mode. It's been on my list for some time to extend the RF12 driver for this, so it can be set in what would be called "promiscuous" mode on Ethernet.
Posted 12/09/2010 11:40:28 -
@jcw: a while ago I tried something like that. My idea was to have a node listen for multiple groups by operating the RF12 in 1 byte sync mode so that it can route between groups. I thought that the group id byte (when the sending nodes keep working the way they do now in 2 byte sync mode) would then appear as part of the data message that is received. However, that wasn't the case. It appears that the second byte is still part of the preamble, but matching to a particular byte is disabled; it will match any value. Consequently, a lot more junk messages will get through as valid RF12 data. So the good thing is that you will receive messages from multiple groups, but unfortunately you can't actually find out what the group id was as this isn't passed through as part of the message data.
On a somewhat related note: because of the junk messages I thought that maybe te valid data detector settings of the radio are set too sensitive, however fiddling with those settings didn't seem to matter a lot. The RF12 somehow seems to lock very easily onto "valid data", or maybe I'm missing something here.
Posted 12/09/2010 21:23:01 -
Andras, the trick is to set the second sync byte, i.e. the configurable one, to 0x2D. IOW, in 1-byte sync mode, the "2nd" byte becomes the 1st (and only) sync byte. Multi-group reception can be done, but the RF12 driver will have to be changed in several places, because of the extra incoming byte, and the CRC logic is uses.
The fact that the RFM12B locks into so many packets in 1-byte mode is more serious. When I had some experimental 1-byte code working, like you, I saw tons of false packets coming in. The problem is that once it has latched onto what it thinks is a valid header, the RF12 driver is going to eat up many bytes - often including any following correct preambles and headers.
So 1-byte mode is going to miss many packets because it makes so many false starts and then keeps eating up the data. I think the only way around that will be to give the driver a set of acceptable group ID's (a small set, maybe implement a fixed limit of 2 or 3), and then have it abort reception immediately when something else comes in. That's a bit like doing the "2nd sync" byte in software. The key is to reset the receiver and get it searching for that 1st sync byte again ASAP after a false start.
Posted 12/09/2010 23:31:40 -
Ah, it seems I confused synchron byte 0 and 1; I thought the configurable one was disabled in 1-byte sync mode which led me to the wrong conclusion. Anyway, good to know that it is possible afterall.
Still, it doesn't seem to be right that so many false packet get through considering that the RF12 has functionality like the Data Quality Detector. I recall having set the DQD treshold to max (7) to see if that would prevent the synchron pattern detector from being enabled when there isn't any FSK signal, but that didn't work. Perhaps it's the clock recovery lock that falsely triggers the pattern detector. Haven't tried setting it to slow mode instead of auto though.
Posted 13/09/2010 19:51:02 -
Andras, tomorrow you'll have some new code to experiment with... at 0:01 to be precise ;)
Posted 13/09/2010 21:23:53 -
Jean-Claude thanks, that's great !
I did some additional test with your new RF12 driver. It looks like it isn't the clock recovery but the DQD that enables the sync pattern detector; changing to slow recovery mode did not matter. Lowering the DQD treshold to zero (not recommended in the datasheet) did increase the false receptions with 200-300%. Maxing the treshold to 7 will decrease the false packet reception with some 30-50%. I did not notice a negative reception range impact in my personal situation here with the max DQD treshold, but it could perhaps affect nodes that are on the edge of your WSN. With the 30-50% reduction there are still quite some false receptions (about 3 false packets/second).
Posted 14/09/2010 11:43:04 -
I've made a little video of the effect group zero reception has over here - as you can see, lots of junk is received between some valid packets -
This isn't really news, but I'm also posting this to find out whether that super-duper video capture program I'm trying out is producing videos which which everyone can view - so please check it out, it's about 20 seconds. I think it's H.264, but I can tweak settings and pick other formats if that works better.
Sooo - does this video work on Windows and Linux, mobiles, tablets, netbooks, iPhones, iPads, etc?
Posted 26/09/2010 11:13:58 -
MPEG4 Video (H264) 800x480 25.00fps Video]
Is there supposed to be any sound as I don't have any audio stream indicated in it?
Plays back fine on my XP machine, but I have Media Player classic and the Klite codec pack which just about pays everything! Works on my Debian Linux box too - no shock there.
And as you asked for mobile - it doesn't work on Nokia N97 Symbian phone, it doesn't natively support H264. It does support flash, so flash video would work, but we all know St Jobs has decreed that is the Devil's work so flash video won't work on iphone/ipad.
What fun!
Standards, we've heard of them!
Posted 26/09/2010 12:14:21 -
Works fine on my Windows Server 2008 (FF Quicktime plugin)
Posted 26/09/2010 12:34:30 -
No sound - correct. My spoken english isn't quite up to it :)
Thanks for the tests. The nice thing about this screen capture (via Snapz Pro) is that it doesn't lose any quality, so things like text remain very readable. I didn't pick H.264 to please Mr. Jobs, but because it seems like as good an option for the long term as any.
Ok, thanks for testing - main remaining unknown now is whether most vanilla WIndows boxes will accept this format.
Cool. Only other thing I still need is a little annotation/caption mechanism when editing such videos (the one above was unedited). So that I can tweak the time-line and inject written comments. I'll leave sound and music soundtracks to the Youtube generation.
Posted 26/09/2010 12:38:35 -
Let me restore my vanilla XP sandbox VM and I'll test it for you. I don't think XP has an MP4 codec by default, but if media player can successfully go and retrieve one automatically (which I have actually seen work in the past), you'll be good to go on the windows front.
As for your spoken English, I suspect you are better than some of my friends (that includes some English ones!)... And not as amusing as a female Polish friend of mine who was hosting a meeting in England and had one of her colleagues pull her aside at the end and tell her she needs to be more careful with how she pronounces "focus"...
Would you like me to time lapse the construction of my JeeNode SMD?
Posted 26/09/2010 12:47:10 -
> Would you like me to time lapse the construction of my JeeNode SMD?
Time lapses are always fun to watch!
Posted 26/09/2010 14:18:56 -
Best I clean my nails then (I've been fiddling with the car!)
Oh, and no laughing at my 40 year old pot of suspected plumbers flux which I inherited from my father!
Posted 26/09/2010 14:48:30 -
Windows 7 OOB (aka vanilla?) works fine.
Posted 26/09/2010 19:08:09 -
Thx - ok, now I got around to doing some tests with Windows myself. Not sure my setup is "vanilla", but probably close.
WinXP leads to a download (32 Mb, ugh), and then this QuickTime movie will play. Not perfect, but workable, IMO.
Win2k doesn't know what to do with a .mov file on my setup. Oh well, that system is probably no longer used by the tech-savvy folks hanging around here.
Methinks I can stick with this.
Posted 26/09/2010 21:47:55 -
Have a look at your web server logs and see how many win2k machines pop by. I would have thought most people would be able to play mp4 mov files by now, even if they've installed that nasty quicktime to do it.
Posted 26/09/2010 22:37:09 -
> Have a look at your web server logs
I don't track web server logs.
(all I see is page visit counts from Wordpress, and even those I've considered turning off)
Posted 26/09/2010 22:48:38 -
Looks like win2k isn't really much of a worry judging by the published stats... http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=10
- Windows XP 60.89% - Windows 7 15.87% - Windows Vista 14.00% - Mac OS X 10.6 2.59% - Mac OS X 10.5 1.73% - Java ME 0.86% - Linux 0.85% - iPhone 0.73% - Mac OS X 10.4 0.55% - Windows 2000 0.40% - iPad 0.27% - Symbian 0.27% - iPod 0.13% - Windows NT 0.10% - Mac OS X (no version reported) 0.10% - Android 2.1 0.09% - BlackBerry 0.09% - X11 0.07% - Windows 98 0.06% - Android 1.6 0.05% - Unknown 0.05% - Android 2.2 0.03% - Windows ME 0.03%
I'm amazed there are any ME installs still running. Last time I played with an install it became infected with 101 evil things before it had a chance to download enough updates to protect itself!
Posted 27/09/2010 01:11:45