Getting started with MiRF v2 (RP-SMA version) and nRF24L01

Wireless & IoT
21

What if you did the ID thing, but with a twist.

You reserve an ID, say 0. All of the receivers are initially setup as id 0, and the transmitter has code to see if something with ID 0 is trying to talk with it, if it is, it assigns it a new ID, and then talks with it as taht ID.

I’m not sure how the transmitter / receivers work, whether or not they talk to each other, or if it would be possible to send a value, have the transmitter switch to that ID, and then continue.

Sorry if this was a wasted post, just an idea!

22

You reserve an ID, say 0. All of the receivers are initially setup as id 0, and the transmitter has code to see if something with ID 0 is trying to talk with it, if it is, it assigns it a new ID, and then talks with it as taht ID.

That's a good idea, but think about the situation when you have a bunch of receivers all talking at the same time at startup. Obviously, only one receiver will be able to talk to the transmitter at a time, so when the transmitter sends that receiver its ID, then there's no way the other receivers will know that the transmitter is not talking to them. Then all the receivers will receive the same packet and take the same ID. Unless maybe there's some way around that that I can't think of right now... :?:
23

I just thought, what if you delayed the startup time on each module, but that would require different firmware for each…

Theres got to be a way…

24

That’s a good idea, and I think it could work. The only problem would be identifying what ids are already taken and making sure they don’t choose the same one.

If there is a way to do that efficiently, then that way might work. When a transmitter or receiver is turned on, its id is 0. A transmitter that turns on identifies ids that are already in use, and picks one that is not. It then sends out a signal with a current id (0 still) and its desired id (whatever is not taken). It continues to do this until it receives a response from a receiver. When a receiver is turned on, it waits for a signal with a current id of 0 (like stated above) and a desired id. When it gets that signal, it sends an “acceptance” signal to the transmitter with id 0 and a desired id of whatever. The transmitter and receiver both become assigned to that id and will remain that way until one is shut down.

So basically, the transmitter sends a signal saying it is ready for a receiver and has picked out a unique id, and a receiver responds saying it will now “attach” to the transmitter. The reciever assigns itself to that id, and when the transmitter receives the acceptance signal, it does the same.

A problem would be if either the transmitter or receiver was turned off or lost power for some reason. Since the 24L01 doesn’t store any settings, everything would be reset. This would mean the link would be broken and could only be reestablished by turning on the transmitter and receiver again and going through the same process. There might be a way to still make it work, like if the transmitter stops getting acknowledgements it resets itself and similar for the receiver, but it might not work that well.

It is a good idea, but it could get to be a mess and could be difficult to manage.

I’m thinking that a user selected channel would work the best. The only problem would be if that channel has interference from something other than the modules for RC, like Bluetooth or something (for example), we would have the same problem as before. If the transmitter could get one packet through to the receiver saying to change the channel, it might not be a problem. I guess if there is too much interference on that channel, the car wouldn’t work right and the user would select another channel.

I guess permanent but unique ids would be the best way for the user but the worst way for the programmer/designer. I would really like it to be automatic so the user doesn’t have to worry about anything, but that could be very difficult. I will probably go with user selected channel switching, my only problem is figuring out a cheap, easy way to show the selected channel. I can’t use LCD screens because 1) I don’t have any experience with them and 2) that could get expensive and take up a lot of space, etc. One way would be a combination of LEDs that show a combination of different colors depending on the channel, but I would like to aboid that if possible. Plus, the more channels there are to choose from, the more LEDs I would have to have.

If only there was an easy way…

25

I agree with you, CPW, that it would be difficult to do the ID thing that reklipz mentioned. LCDs can be a pain to wire up, but they’re really not terribly hard to deal with. Here’s a link to some insanely cheap LCDs: http://character-lcd-lcds.shopeio.com/i … cter%20Lcd. I have ordered from them several times, but I think they have a minimum order of 20 bucks. Here’s a good reference on interfacing to standard character LCDs that I have used extensively: http://www.myke.com/lcd.htm. To help you even more, C18 has a built-in library for interfacing to LCDs (I think it’s called XLCD or somethin like that). But I guess if you’re using basic, you’re out of luck with that one.

Another idea that came to mind is using one or more 7-segment displays. You could display your number that way in a very readable format. They’re simple to deal with (until you have to start multiplexing them). You can also use 74HC595 logic chips to power them. The 595 will hook up directly to your SPI port, so you will only need one extra pin to use as many 7-segment displays as you want (the necessary pin would be a chip select for the 595’s). Here’s the link to a 595 datasheet: http://www.fairchildsemi.com/ds/MM/MM74HC595.pdf. For this scheme, you would hook up one 595 per 7-segment LED, and the 595’s would be cascaded so that you can use as many as you like.

26

Thanks for the information. I’ll look into LCDs and 7 segment displays.

27

I did implement something similar which I called “plug and play”, before Zigbee came out with a better thing .

:smiley:

Basically, I reserved address 0 as invalid, and 255 as broadcast. When created and powered, each node had address “zero” which meant “go asking an address”. The coordinator (in Zigbee terms) or central unit would listen for such requests and assign them an unique address, holding a table of them. The node would store that address in EEPROM. The Central unit is always able to reset them, in case of need, and assign another.

Moreover, if two devices with same address come in touch, one of them (the latter) will self-delete and restart with “zero”.

This works good enough by now. Only problem that arises is that you can’t know “where exactly” (physically, I mean, in your topology) any address will go. No place to force them. Not so bad, anyway. In any case, I renumber them manually, once the whole process has completed, for the sake of clarity.

Recently I came out with the idea of having a “string” made of 4 char programmed sequentially into the Chip, and this string comes along with the PNP request: so the Central Unit has a mean to know “where” that request does come from. Of course, using same mechanism, also Fixed Addresses could be assigned at program time… maybe!

As for the collision in requests, I use a random time after power up, before sending out the request. This should guarantee that all nodes get their addresses, at least at 2nd shoot. Besides I also implement some CSMA/CD, waiting a random amount of time (growing at each try) before sending out packets.

In the end, I’d not use separate RF channels to address each node: seems a bad idea, and it’s better left out for improving interferences.

28

Well, when I came up with that Idea, i was under the impression that there was one transmitter (one, “base” i guess) and lots of receivers. I guess if I had read the thread more thoroughly, i would have realized this was wrong.

As far as an easy way to get the user to select a channel:

What if you put like a 10K POT on each one, and then, used the ADC to check what the value of the POT was, and then had some sort of knob that would “click” into preset positions, so the user wouldnt have to worry about lining it up with a line, it would just click into one of the preset places. You would then use the ADC to read this, periodically, and switch the channel accordingly.

If not, the Up/Down channel buttons with the 7-seg display would be really cool and much more user friendly.

29

You could always try a detented rotary encoder. The detented ones have a preset number of “clicks”, such that the rotation is not continuous, but is in discrete steps. They’re similar in construction to a pot, but they output digital values relative to the position of the rotor mechanism. Check out this link: http://www.parallax.com/dl/docs/cols/nv … ol/nv8.pdf.

30

An italian firm uses resistive jumper to set the address, up to 10, and they have different resistive values.

31

CPW, you could also try DIP switches would serve the same purpose as jumpers but could be changed at any time.

32

oooh. DIP switches would be good, but you have to be careful if its a non technical user…

You could run the DIP to a parallel → shift register, and just pull that into the PIC.

33

The shift register reklipz is mentioning is the 74HC165, sort of the brother of the 74HC595 I mentioned in an earlier post. The 165 is parallel in, serial out, whereas the 595 is the opposite. The 165 can also be connected to the SPI bus, but it needs a buffer that can go to high-impedance on its output pin. This is because its output is always active, even when its chip select pin is not active, which violates the rules for devices on SPI bus. The reason this is bad is that if you want to talk to another device on the bus, then the 165 could be trying to put 0V on the bus, but the other device might try to put 3.3V on the bus. If you know anything about electronics, then you can see that magic smoke is probably going to be released if this happens.