Duane,
Since the SparkFun Nordic transceiver board has a voltage regulator to handle more than 3.3V and I believe the nRF24L01+ has an internal one, bypassing the one on the PCB might make it draw less current.
The nRF24L01+ standard transceiver board just has the nRF chip, a crystal and antenna-matching circuit. It should therefore take 0.9uA in power down mode, 26uA in standby mode, 11mA on TX and 13mA on RX.
The higher power nRF24L01+ board (+20dBm) has a PA+LNA and some antenna switching circuitry - don't know if that supports micropower, haven't tested it.
I can receive the information from the Nordic FOBs.
Here's the output from pressing the buttons in a clockwise order. I started at the top and finished with the center button.
Start of Nordic Stress Reduction Buttons
Nordic Started
Press any key to start.
<snipped>
Press any key to start.
Press any key to start.
Press any key to start.Receiver configured.
Receiving only.
Status = %01100000
Received: <$1E><$02><$A6><$00>
Status = %01100000
Received: <$17><$02><$A7><$00>
Status = %01100000
Received: <$1D><$02><$A8><$00>
Status = %01100000
Received: <$1D><$02><$A9><$00>
Status = %01100000
Received: <$1F><$02><$AA><$00>
Status = %01100000
Received: <$0F><$02><$AC><$00>
Status = %01100000
Received: <$0F><$02><$AD><$00>
The first byte indicates which button was pressed. The second and third bytes are a count of the times any button had been pressed. The fourth and final byte is always zero.
The FOB program does not do a very good job at debouncing as can be seen by the duplicate button data. I pressed each button only once for this test.
The "Press any key to start." lines are part of my debugging right now. My finished program wont wait for a key press to start.
One could use the button press count as a way of distinguishing between more than one FOB. You'd probably want limit button presses when the FOB isn't within communication range of the Prop.
I would very much like to reprogram the FOBs. Four bytes isn't enough data to use with the other units and add all the features I'd like to add (check in schedule, message hopping, etc.).
I'm attaching the code to receive the FOB data in case any of you want to use the FOBs before I have my final code ready.
I decided to start calling the project "Nordic Stress Reduction Buttons." Since I want the button's presence to have a calming influence.
Duane
Edit(3/11/15): Warning, the code attached is an old version. There are better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't a replacement on GitHub send me a message and I'll make sure to upload the replacement code.
I received the six modules from Hong Kong yesterday.
These modules are from a seller Mark_T recommended in post #13 of the driver thread.
I tested all six units today. They all both send and receive just fine.
I measured the current used by all six. These measurements were taken while the units were waiting for an incoming message.
Unit #1 drew 13.47mA
Unit #2 drew 13.57mA
Unit #3 drew 13.46mA
Unit #4 drew 13.62mA
Unit #5 drew 13.56mA
Unit #6 drew 13.41mA
Average of all six units = 13.515mA.
I also tested the current draw of several SparkFun units.
SFE #1 (screw on antenna) 14.22mA
SFE #2(screw on antenna) 14.18mA
SFE #3 (chip antenna) 14.01mA
Average of three SFE units = 14.137
So far the range of all the units has been pretty good. The Nordic FOBs appear to have the shortest range of the four types of Nordic modules I now own.
The FOBs could transmit from one room to the next without a problem.
I think I might have a way of saving a lot of time on this project.
Is it a bad idea to power peripheral devices directly by the Prop?
Since all of the Nordic devices use less than 15mA of current, why not just power them directly from the Prop?
I had planned to make a bunch of these adapters to use the Nordic modules with the Propeller.
What if I cheated and just plugged the unit into the QuickStart's header?
I could just set the IO pin connected to Vdd high and the IO pin connected to Vss low.
I wouldn't think sourcing and sinking 14.7mA would hurt the Prop. I'll avoid having both Vdd and Vss within a single group of eight pins (P0 to P7, P8 to P15, P16 to P23 and P24 to P31). I can avoid having Vdd and Vss on a single group of eight pins when I use the SparkFun modules but the Hong Kong (eBay) modules have Vdd and Vss right next to each other so I wouldn't be able to separate the pins into different Prop pins sets.
Here's one of the Hong Kong modules plugged into the QS.
Using Propeller IO pins as power pins would save me a lot of time. Unless someone can tell me a good reason not to do so, I think I'll take this shortcut.
This shortcut would also save me from soldering headers onto the 3.3V and ground connections. I need one 3.3V connection for the button circuit. There is one 3.3V location on the QS's 40-pin header. This would be enough for my planned needs if I don't need a 3.3V location for the Nordic module.
Please let me know if any of you can think of a reason not to proceed with this plan.
I shelved the BS2 attempt for a while and loaded your code to the Propeller.
It works (mostly), however, I get $1B for the 9 o'clock button instead of the $1F you put in your comments. Sometimes I do get $1F but only if I get a secondary debug display for a single keypress.
It can be a little quirky! I have also gotten $13 returned... Peculiar!
I figured out the values transmitted from the Nordic key FOB.
When held with the opening in the case at the top (see pic) and the keys labeled Top, Bottom, Left, Right and Center, this table shows the transmitted values:
$1E = %11110 = Top
$1D = %11101 = Bottom
$1B = %11011 = Left
$17 = %10111 = Right
$0F = %01111 = Center
Each bit in the transmitted value relates to particluar button.
Pressing two buttons at the same time gives appropriate results.
e.g. Top & Bottom = $1C = %11100
Center & Left = $0B = %01011
Sometimes the FOB sends $1F (%11111) which indicates no button pushed!
Seems like bug or timing issue...
For this current project, I don't care which button has been pressed. I want any button to trigger an alert.
I did purchase several extra FOBs for other projects. I'm sure I'll use your information in future FOB projects.
All those keeping score at home,
Powering the Nordic modules from the Propeller's IO pins turns out to be as bad of an idea as it initially sounded.
The modules would not stay properly configured. I was working out ways of turning the modules off and back on again to reset them. I finally decide it would be less work to make some connectors for the modules.
I've been trying to work out a schedule to keep the various units from talking over each other. I think I've made some progress. I'll need to test the device with the new connectors before I know for sure.
Time to power up the soldering iron.
Wasn't I going to be finished with this last Friday?
Fortunately my in-laws have another system in place that seems to be working pretty well. I still want to finish these buttons to see if they (my in-laws) would rather use them (the panic buttons).
If press the buttons on the FOB too quickly or if I have too many units transmitting at the same time, the nRF24L01+ units freeze up.
When I read the status, it come back %00000000.
I thought maybe the device wasn't communicating anymore so I threw in a SpiCheck method. The SpiCheck method reads the rx address of the module, writes a different address and then reads back the address to make sure it matches the one just written.
Here's the output.
Loop Status = %00000000
Powering down device.
Configuring device.
loop config status = %00000000
Attempting to read rx address from module.
rx address = $E7E7E7E7E7
Attempting to write following rx address to module: $AABBCCDDEE
Reading rx address from module: $AABBCCDDEE
!!!!Success!!!!
The rx address was successfully changed.
The test rx address will not necessarily be the rx address used
in communicating with other modules.
Configuring device.
post SpiCheck config status = %00000000
I've tried restarting the driver, powering the down the unit for two seconds and then powering it back up. By powering down, I mean writing a power down bit in the config register.
The only option left, I can think of, is to use a relay to cut the power to the units and then use the relay to turn them back on.
I figure a latching relay or a normally closed relay, wont use too much power.
Any other ideas?
I'm attaching the code I'm using right now.
I haven't added code to monitor the physically connected buttons yet. So far the code just listens for the FOB units and then passes the message that a FOB has been detected from unit to unit.
Any insight would be appreciated.
Just a warning: The code writes data to the EEPROM.
I keep the "button ID" in upper EEPROM so I can use the same code on all the units. The code uses the button ID to determine when it is the unit's turn to transmit.
Here, I'll attach the code to write the button ID to upper EEPROM.
Just change this part to match the ID you want written.
CON
_IdToAssign = 3 '2 '1 '0 '
I think any value up to 6 will work for now. Use a different ID number for each unit to keep them from transmitting over the top of each other.
If any of you do try this code out make sure and change the pin assignments to match your setup.
Duane
Edit(3/11/15): Warning, the code attached is an old version. There are better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't a replacement on GitHub send me a message and I'll make sure to upload the replacement code.
Duane,
I noticed that you pause, reload the TX address and then set the config register back to PRX.
That seems to fix the problem but I don't know why...
outa[SpiCe]~~
waitcnt(1000 + cnt) ' > 10us 800 = 10 us @ 80MHz
outa[SpiCe]~ ' Spin might be slow enough not to need a delay
outa[SpiCsn]~
SpiWrite(W_REGISTER + TX_ADDR) ' I shouldn't need to do this. Now I do.
repeat localIndex from 0 to 4 ' I set this in the config method
SpiWrite(txAddress[localIndex]) ' **** test to see if this still works
outa[SpiCsn]~~ ' **** with address write removed
outa[SpiCsn]~
SpiWrite(W_REGISTER + CONFIG)
SpiWrite(byte[configPtr])
outa[SpiCsn]~~
'Start receiving
outa[SpiCe]~~
Duane, I noticed that the transmitting transceiver won't work if I reset the Config register back to PRX at the end of the transmit procedure.
This is true in both the SPIN version and the PBasic version.
I wonder if there is something that needs to be done when switching between PRX and PTX mode.
Any thoughts?
Ron,
So are you unable to receive messages once the unit has transmitted?
I seem to be able to switch back and forth between transmitting and receiving.
If I press the buttons on the FOB really fast the receiving unit freezes up.
I've just about decided the only way to unfreeze the unit is to cycle the power.
As long as the unit hasn't locked up, I can switch back and forth between rx and tx.
Here's the tx method.
PUB TransmitString(localPtr) | localIndex
'' For now this method transmit the a full payload of bytes starting with
'' the memory location "localPtr".
'' I'd like to add the ability to transmit strings larger than the
'' payload size. I'll need to learn to use the auto retransmit
'' ability of the new modules. I also want to come up with a system
'' of acknowledging packets when using older modules.
{if localTarget <> previousTarget
SetAddress(targetId, @txAddressTarget)
previousTarget := localTarget
}
outa[SpiCe]~
'Take out of rx mode
outa[SpiCsn]~
SpiWrite(W_REGISTER + _STATUS)
SpiWrite(statusReset) ''' statusReset = %01000000 if added code to the top object
'''to reset some of the other bits.
outa[SpiCsn]~~
outa[SpiCsn]~
SpiWrite(W_REGISTER + CONFIG)
SpiWrite(byte[configPtr] - 1) ' PTX mode ''' this should be %00111010 for PTX mode
outa[SpiCsn]~~
outa[SpiCsn]~
SpiWrite(FLUSH_TX)
outa[SpiCsn]~~
outa[SpiCsn]~
SpiWrite(W_TX_PAYLOAD)
Spi.ShiftOutStr(localPtr, payloadSize)
outa[SpiCsn]~~
outa[SpiCe]~~
waitcnt(1000 + cnt) ' > 10us 800 = 10 us @ 80MHz
outa[SpiCe]~ ' Spin might be slow enough not to need a delay
outa[SpiCsn]~
SpiWrite(W_REGISTER + TX_ADDR) ' I shouldn't need to do this.
repeat localIndex from 0 to 4 ' I set this in the config method
SpiWrite(txAddress[localIndex]) ' **** test to see if this still works
outa[SpiCsn]~~ ' **** with address write removed
outa[SpiCsn]~
SpiWrite(W_REGISTER + CONFIG)
SpiWrite(byte[configPtr]) ''' this should be %00111011 this should put into PRX mode
outa[SpiCsn]~~
'Start receiving
outa[SpiCe]~~
I'm going to go back and add some comments.
I'm using triple " ' " marks to indicate I just added the comment.
I think most of the above code is still heavily based on Leon's C code.
As I said, this code works most of the time. I sure wish I could figure out how to preform a soft reset. Until then, I'll keep working on my add on board that uses a latching relay to reset the Nordic module.
Duane,
I noticed that you pause, reload the TX address and then set the config register back to PRX.
That seems to fix the problem but I don't know why...
outa[SpiCe]~~
waitcnt(1000 + cnt) ' > 10us 800 = 10 us @ 80MHz
outa[SpiCe]~ ' Spin might be slow enough not to need a delay
outa[SpiCsn]~
SpiWrite(W_REGISTER + TX_ADDR) ' I shouldn't need to do this. Now I do.
repeat localIndex from 0 to 4 ' I set this in the config method
SpiWrite(txAddress[localIndex]) ' **** test to see if this still works
outa[SpiCsn]~~ ' **** with address write removed
outa[SpiCsn]~
SpiWrite(W_REGISTER + CONFIG)
SpiWrite(byte[configPtr])
outa[SpiCsn]~~
'Start receiving
outa[SpiCe]~~
I don't know either. I did it because Leon did it.
I wonder if there is some other trick like this to unfreezing the units. I know I can still communicate with them through the SPI link. I just don't know what else to try.
I'm not sure if I've tried transmitting a message when the unit is locked up. That would be an easier solution than adding a relay. I think I'll give a try right now.
Can you get your units to lock up by pressing the FOB buttons fast?
I don't know either. I did it because Leon did it.
I wonder if there is some other trick like this to unfreezing the units. I know I can still communicate with them through the SPI link. I just don't know what else to try.
I'm not sure if I've tried transmitting a message when the unit is locked up. That would be an easier solution than adding a relay. I think I'll give a try right now.
Can you get your units to lock up by pressing the FOB buttons fast?
Duane
No, mine never locks up but sometimes I get a $1F code. I am using SPI_ASM though...
- Ron
Have you tried pressing a button on the FOB really fast? Like vibration fast.
That's one way mine will lock up. The other way is to have a bunch (I had four at once) of the Nordic modules communicating at the same time.
I think I'll go back and see if they lock up with the SPI_ASM version of the driver. This application doesn't need the speed of the faster driver.
Duane
Well, don't know about "vibration fast" but as fast as I can push them
When I have a BS2 emulating the FOB repeatedly sending the five button codes in succession at a fast rate, some "button pushes" get lost, but it never locks up.
I mentioned earlier my desire to use rgb LEDs to indicate which button unit had been activated.
I wrote a little driver to control the LED.
The LED I'm using is a common cathode.
Here are some of the important methods.
PUB Init(localRedPin, localGreenPin, localBluePin)
'' Call Init method to assign pin numbers.
'' This needs to be called before calling other methods.
The "Init" method is used to define the pins.
PUB FlashLed(redByte, greenByte, blueByte, localFlashPeriod, localCycleCount)
'' redByte how much of the on time should the red LED be on.
'' greenByte how much of the on time should the green LED be on.
'' blueByte how much of the on time should the blue LED be on.
'' All three color numbers should be between zero and 255.
'' flashTime period of a flash cycle in milliseconds.
'' The LED will be on half of the flash cycle.
'' localCycleCount is how many times to flash.
'' if localCycleCount is zero then the LED will continue to flash
'' until a different instruction is given.
'' If the driving cog has not been started, this method will start the cog.
The "FlashLed" method flashes the LED. The driver uses PWM to control the brightness of each color. The brightness level is an eight bit number (byte). The PWM frequency is about 4.3kHz. The LED is on one half of "flashTime" and off the other half. "flashTime" is in units of milliseconds.
"localCycleCount" is number of times you want the LED to be flashed. If a zero is used for this value then the LED will continue to flash until the object receives a different command.
PUB SolidLed(redByte, greenByte, blueByte, localOnTime) | localIndex, localTime, {
} changeTime, largeLoopStartTime, temp[6]
'' redByte how much of the on time should the red LED be on.
'' greenByte how much of the on time should the green LED be on.
'' blueByte how much of the on time should the blue LED be on.
'' All three color numbers should be between zero and 255.
'' onTime time LED is on in milliseconds.
'' If onTime is set to zero then the LED will stay on
'' until a different instruction is given.
'' If the driving cog has not been started, this method will start the cog.
"SolidLed" turns on the LED for the amount of time designated by "localOnTime". Once again the units are milliseconds. If a zero is used then the LED will stay on until the object receives a different command.
The color of the LED can be changed while it is on by using the "ChangeColor" method.
PUB ChangeColor(redByte, greenByte, blueByte)
'' redByte how much of the on time should the red LED be on.
'' greenByte how much of the on time should the green LED be on.
'' blueByte how much of the on time should the blue LED be on.
'' All three color numbers should be between zero and 255.
The driver frequently checks the color variables in hub RAM. Either a solid or flashing LED can have its color changed using the "ChangeColor
There is an "Off" method that turn the LED off without stopping the driver cog.
I think this object will make it easier to control a red, green and blue LED.
Duane
Edit(3/11/15): Warning, the code attached is an old version. There are better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't a replacement on GitHub send me a message and I'll make sure to upload the replacement code.
I've been busy soldering all the wires needed to make multiple units.
I've added a couple of features to the RGB LED code. The code will now blink the LED between two different colors. I thought this would allow more information to be conveyed with the LED.
I thought I'd post a picture of one of the ways I'm attaching the cheap eBay Nordic modules to the QuickStart boards.
I'm actually using P0 - P5 for the modules. I moved the position of the module to allow more room on the 40-pin header for the connection to a secondary board.
The above connection has the advantage of being very easy to make. Here's a picture of the parts.
I said earlier that hardware is easy and software is hard. The problem comes when you're trying to make multiples of a prototype. It not hard to copy the software six times but building six copies of the hardware prototype can take a lot of time.
I need at least three copies before I can test all the features of these devices. I hope to have three (maybe four) units up and running today.
I've been away from the forums here for many weeks so I'm really
late to this thread. But I thought I'd add a few comments about small
panic button type transmitters and cheap enclosures. Someone might
find the ideas useful.
I started working on a project a few months ago to create small and
very inexpensive sensors that could be placed just under the ground
and be able to send data to a cheap receiver a few hundred feet away.
I came up with some rather odd but workable ideas. First I decided to
use those really cheap crystal oscillators for the transmitters. These
are mostly used instead of crystals when working with uC's. I used a
tiny85 uC to key these small transmitters and send short data strings
back to a receiver box which contained a cheap digital radio I bought
on Ebay and a small circuit board that has a Tiny88, a tone decoder
chip (LM567) and a 3.00 USD 2 line LCD display and a small speaker
for sounding an alarm tone. This setup gives you an intrusion alarm
system that alerts you to someone approaching outside. The multiple
buried sensor devices each have a unique string of data they send back
so you know which ones have been set off.
I got the idea of what to use for the cheap enclosures for the sensors
from making tuna sandwiches in the small kitchen we have here. The
can opener works by cutting into the side of the can lid instead of the
normal way of cutting the top. This leaves you with a small can that has
a lid that fits back on the can instead of a round piece of useless sharp
scrap. This is of course nice for putting left-over tuna into the fridge. It
occurred to me that these cans with their nice lids could be used as
zero cost enclosures. What I came up with is to drill a tiny hole in the
center of the lid and one in the center of the bottom of the can. Then you
cut off a small section of small wooden dowel rod that is just slightly
shorter than the height of the can. You drill small pilot holes in the ends
of the piece of dowel and then you use a small screw to hold the dowel
in place inside the can, screwing into the dowel through the bottom of
the can. Then you can close the can by just putting the fitted lid on top
and using another screw to fasten the lid down tightly using the screw to go
through the lid and into the dowel. For weatherproofing I sealed the screw
holes and the can lid rim using a thin coat of silicone caulk...the clear
sort that never gets stiiff and hard but remains rubbery. Then I coated the
enclosure with 2 coats of gray primer paint using a spray can. If you do
not need the enclosure to be water tight then these steps can be omitted.
Inside the can is the small circuit board with a proximity sensor I thought of
and the uC. Power is from a small battery and life is long as the uC is in
sleep mode nearly all the time, waking only briefly on a schedule that can
be set using capacitive touch sensing to send data to the uC by code. A small
wire antenna exits from the can top through a tiny hole drilled on a slant
through the lid and the dowel, this serves as the cap touch sensor as well as
antenna. The unit is placed in the ground with only a thin layer of dirt covering
the can top. The antenna is insulated and protrudes a few inches above ground.
The zero cost enclosure idea and the use of those cheap oscillators as rf sources
seemed to be relevant to this thread :-)
When I was playing with this project someone remarked that the units looked
like little gray landmines..lol So I called them Land Minds since they have a
very weak mind inside consisting of the tiny85.
I should have somehow mounted a small LED through the top of the enclosure
though as it would have been easier to use when sending commands to change
the operation of the uC using the touch sensor. As it is you have to carry a small
radio to hear feedback from the oscillator being keyed by the uC....it's a pain.
The units are in power down mode where they only wake and check for input
once a minute...to wake them you have to hold them by the antenna until they
send 3 beeps to the radio and then quickly enter a code to activate them. It's
kind of cool that they have no mechanical switches of any kind, not even a power
switch was needed since in the 'power down mode' the battery lasts almost as long
as it would if it was just sitting on a shelf.
It's good to have you back. I've been wondering how you were doing on your "secret mission". Now I know you've been laying Land Minds.
I'm often looking for cheap enclosures. I like your tuna can idea.
Are these Land Minds something you can post schematics for? They sound very interesting. How is the intruder detected? Is it through the capacitance sensor you mentioned?
How do your Land Minds know to wake up? I think this stuff is beyond my current electronics knowledge especially using "cheap crystal oscillators for the transmitters".
I'm often looking for cheap enclosures. I like your tuna can idea.
Are these Land Minds something you can post schematics for? They sound very interesting. How is the intruder detected? Is it through the capacitance sensor you mentioned?
How do your Land Minds know to wake up? I think this stuff is beyond my current electronics knowledge especially using "cheap crystal oscillators for the transmitters".
The ideas were all mine (pun intended ;-)
The hardware I had to get help for since I have limited
electronics skills. I did the programming and a guy
I used to work with did the hardware design from my
descriptions and designed the boards. the sensor Idea
came to me from some reading I was doing on another
problem totally unrelated to this kind of thing. The idea
turned out to be pretty unique so I am keeping it quiet.
The hardware design is not mine so I don't feel free to just
post the details or board design. The program code is
nothing at all special and could be duplicated by anyone.
The tuna can idea was just a lucky notion that popped
into my head while I was making a sandwich. It also works
with cans of all sizes. You must have one of those fancy
side cutting openers though. The enclosures are really sturdy
and tightly closed once you put in the screws...and the
price is right. They sell other sorts of meat and fish in small
squarish cans that have rounded edges here. These might
make even nicer enclosures for projects but I have not tried
one since I only like tuna salad sandwiches :-)
The uC wakes up on a regular schedule and exits sleep mode
to check things and send a signal if required. It's just standard
timer stuff.
If you have one of those side cutting can openers go ahead and
try making an enclosure as I described...you will be pleased.
It's a bit like the craze to use Altoids boxes as enclosures only
these are more sturdy and even cheaper since everyone opens
cans all the time...I mean, how many Altoids can a guy eat anyway.
Comments
The nRF24L01+ standard transceiver board just has the nRF chip, a crystal and antenna-matching circuit. It should therefore take 0.9uA in power down mode, 26uA in standby mode, 11mA on TX and 13mA on RX.
The higher power nRF24L01+ board (+20dBm) has a PA+LNA and some antenna switching circuitry - don't know if that supports micropower, haven't tested it.
In case you are interrested in a somehow different approach look at a popular solution around here: http://www.emporialifeplus.com/index.php?id=emporia_life_plus_mobile_phone_for_the_elderly
Good luck Hermann
Here's the output from pressing the buttons in a clockwise order. I started at the top and finished with the center button.
The first byte indicates which button was pressed. The second and third bytes are a count of the times any button had been pressed. The fourth and final byte is always zero.
The FOB program does not do a very good job at debouncing as can be seen by the duplicate button data. I pressed each button only once for this test.
The "Press any key to start." lines are part of my debugging right now. My finished program wont wait for a key press to start.
One could use the button press count as a way of distinguishing between more than one FOB. You'd probably want limit button presses when the FOB isn't within communication range of the Prop.
I would very much like to reprogram the FOBs. Four bytes isn't enough data to use with the other units and add all the features I'd like to add (check in schedule, message hopping, etc.).
I'm attaching the code to receive the FOB data in case any of you want to use the FOBs before I have my final code ready.
I decided to start calling the project "Nordic Stress Reduction Buttons." Since I want the button's presence to have a calming influence.
Duane
Edit(3/11/15): Warning, the code attached is an old version. There are better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't a replacement on GitHub send me a message and I'll make sure to upload the replacement code.
Thanks for posting your code. I should get my FOBs and receivers tomorrow. I will try your code.
Are you using 3.3v or 5v to power the receiver?
I will also see if I can get a Basic Stamp to work with the units.
- Ron
I'm powering all the modules with 3.3V.
I think the regulator on the SparkFun units increases the current used by about 0.6mA.
I'd think these would work with a Basic Stamp. I don't know if there is a driver for the BS or not.
I'm going to post an update real soon. I wanted to answer your question first.
Duane
These modules are from a seller Mark_T recommended in post #13 of the driver thread.
I tested all six units today. They all both send and receive just fine.
I measured the current used by all six. These measurements were taken while the units were waiting for an incoming message.
Unit #1 drew 13.47mA
Unit #2 drew 13.57mA
Unit #3 drew 13.46mA
Unit #4 drew 13.62mA
Unit #5 drew 13.56mA
Unit #6 drew 13.41mA
Average of all six units = 13.515mA.
I also tested the current draw of several SparkFun units.
SFE #1 (screw on antenna) 14.22mA
SFE #2(screw on antenna) 14.18mA
SFE #3 (chip antenna) 14.01mA
Average of three SFE units = 14.137
So far the range of all the units has been pretty good. The Nordic FOBs appear to have the shortest range of the four types of Nordic modules I now own.
The FOBs could transmit from one room to the next without a problem.
Duane
Is it a bad idea to power peripheral devices directly by the Prop?
Since all of the Nordic devices use less than 15mA of current, why not just power them directly from the Prop?
I had planned to make a bunch of these adapters to use the Nordic modules with the Propeller.
What if I cheated and just plugged the unit into the QuickStart's header?
I could just set the IO pin connected to Vdd high and the IO pin connected to Vss low.
I wouldn't think sourcing and sinking 14.7mA would hurt the Prop. I'll avoid having both Vdd and Vss within a single group of eight pins (P0 to P7, P8 to P15, P16 to P23 and P24 to P31). I can avoid having Vdd and Vss on a single group of eight pins when I use the SparkFun modules but the Hong Kong (eBay) modules have Vdd and Vss right next to each other so I wouldn't be able to separate the pins into different Prop pins sets.
Here's one of the Hong Kong modules plugged into the QS.
Using Propeller IO pins as power pins would save me a lot of time. Unless someone can tell me a good reason not to do so, I think I'll take this shortcut.
This shortcut would also save me from soldering headers onto the 3.3V and ground connections. I need one 3.3V connection for the button circuit. There is one 3.3V location on the QS's 40-pin header. This would be enough for my planned needs if I don't need a 3.3V location for the Nordic module.
Please let me know if any of you can think of a reason not to proceed with this plan.
Duane
I decided to try a BS2 program first.
For some reason the IRQ pin is always HIGH -
I used your "Prop Listen for Nordic FOB Constants".
Here is a Debug display of the config regs...
Time to double-check all my code...
It works (mostly), however, I get $1B for the 9 o'clock button instead of the $1F you put in your comments. Sometimes I do get $1F but only if I get a secondary debug display for a single keypress.
It can be a little quirky! I have also gotten $13 returned... Peculiar!
The FOB does seem to have a short range (indoors at least). I wonder if an antenna improvement might help...
- Ron
I started a new thread in the Wireless forum and attached the BS2 code
http://forums.parallax.com/showthread.php?133053-Nordic-nRF24L01-BS2-Code-example&p=1018435#post1018435
When held with the opening in the case at the top (see pic) and the keys labeled Top, Bottom, Left, Right and Center, this table shows the transmitted values:
$1E = %11110 = Top
$1D = %11101 = Bottom
$1B = %11011 = Left
$17 = %10111 = Right
$0F = %01111 = Center
Each bit in the transmitted value relates to particluar button.
Pressing two buttons at the same time gives appropriate results.
e.g. Top & Bottom = $1C = %11100
Center & Left = $0B = %01011
Sometimes the FOB sends $1F (%11111) which indicates no button pushed!
Seems like bug or timing issue...
Thanks for posting the FOB's button code.
For this current project, I don't care which button has been pressed. I want any button to trigger an alert.
I did purchase several extra FOBs for other projects. I'm sure I'll use your information in future FOB projects.
All those keeping score at home,
Powering the Nordic modules from the Propeller's IO pins turns out to be as bad of an idea as it initially sounded.
The modules would not stay properly configured. I was working out ways of turning the modules off and back on again to reset them. I finally decide it would be less work to make some connectors for the modules.
I've been trying to work out a schedule to keep the various units from talking over each other. I think I've made some progress. I'll need to test the device with the new connectors before I know for sure.
Time to power up the soldering iron.
Wasn't I going to be finished with this last Friday?
Fortunately my in-laws have another system in place that seems to be working pretty well. I still want to finish these buttons to see if they (my in-laws) would rather use them (the panic buttons).
Duane
So here's some of the easy part I've been working on.
The button came with a riser but I thought it looked better without it.
Since I didn't use the riser, I had to cut a really big hole in the PVC cap.
I think it looks pretty cool.
I doubt I'll have more than one of these big red buttons in use as a panic button.
I'll use a separate post to describe my software woes.
Duane
I can't seem to keep these Nordic units happy.
If press the buttons on the FOB too quickly or if I have too many units transmitting at the same time, the nRF24L01+ units freeze up.
When I read the status, it come back %00000000.
I thought maybe the device wasn't communicating anymore so I threw in a SpiCheck method. The SpiCheck method reads the rx address of the module, writes a different address and then reads back the address to make sure it matches the one just written.
Here's the output.
I've tried restarting the driver, powering the down the unit for two seconds and then powering it back up. By powering down, I mean writing a power down bit in the config register.
The only option left, I can think of, is to use a relay to cut the power to the units and then use the relay to turn them back on.
I figure a latching relay or a normally closed relay, wont use too much power.
Any other ideas?
I'm attaching the code I'm using right now.
I haven't added code to monitor the physically connected buttons yet. So far the code just listens for the FOB units and then passes the message that a FOB has been detected from unit to unit.
Any insight would be appreciated.
Just a warning: The code writes data to the EEPROM.
I keep the "button ID" in upper EEPROM so I can use the same code on all the units. The code uses the button ID to determine when it is the unit's turn to transmit.
Here, I'll attach the code to write the button ID to upper EEPROM.
Just change this part to match the ID you want written.
I think any value up to 6 will work for now. Use a different ID number for each unit to keep them from transmitting over the top of each other.
If any of you do try this code out make sure and change the pin assignments to match your setup.
Duane
Edit(3/11/15): Warning, the code attached is an old version. There are better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't a replacement on GitHub send me a message and I'll make sure to upload the replacement code.
The pictures are of some of my attempts of connecting some of the hardware I'm using in this project to the QuickStart boards.
I'm still working on other ways of connecting the needed devices to the QuickStart boards.
Duane
Duane, I noticed that the transmitting transceiver won't work if I reset the Config register back to PRX at the end of the transmit procedure.
This is true in both the SPIN version and the PBasic version.
I wonder if there is something that needs to be done when switching between PRX and PTX mode.
Any thoughts?
I noticed that you pause, reload the TX address and then set the config register back to PRX.
That seems to fix the problem but I don't know why...
outa[SpiCe]~~ waitcnt(1000 + cnt) ' > 10us 800 = 10 us @ 80MHz outa[SpiCe]~ ' Spin might be slow enough not to need a delay outa[SpiCsn]~ SpiWrite(W_REGISTER + TX_ADDR) ' I shouldn't need to do this. Now I do. repeat localIndex from 0 to 4 ' I set this in the config method SpiWrite(txAddress[localIndex]) ' **** test to see if this still works outa[SpiCsn]~~ ' **** with address write removed outa[SpiCsn]~ SpiWrite(W_REGISTER + CONFIG) SpiWrite(byte[configPtr]) outa[SpiCsn]~~ 'Start receiving outa[SpiCe]~~Ron,
So are you unable to receive messages once the unit has transmitted?
I seem to be able to switch back and forth between transmitting and receiving.
If I press the buttons on the FOB really fast the receiving unit freezes up.
I've just about decided the only way to unfreeze the unit is to cycle the power.
As long as the unit hasn't locked up, I can switch back and forth between rx and tx.
Here's the tx method.
PUB TransmitString(localPtr) | localIndex '' For now this method transmit the a full payload of bytes starting with '' the memory location "localPtr". '' I'd like to add the ability to transmit strings larger than the '' payload size. I'll need to learn to use the auto retransmit '' ability of the new modules. I also want to come up with a system '' of acknowledging packets when using older modules. {if localTarget <> previousTarget SetAddress(targetId, @txAddressTarget) previousTarget := localTarget } outa[SpiCe]~ 'Take out of rx mode outa[SpiCsn]~ SpiWrite(W_REGISTER + _STATUS) SpiWrite(statusReset) ''' statusReset = %01000000 if added code to the top object '''to reset some of the other bits. outa[SpiCsn]~~ outa[SpiCsn]~ SpiWrite(W_REGISTER + CONFIG) SpiWrite(byte[configPtr] - 1) ' PTX mode ''' this should be %00111010 for PTX mode outa[SpiCsn]~~ outa[SpiCsn]~ SpiWrite(FLUSH_TX) outa[SpiCsn]~~ outa[SpiCsn]~ SpiWrite(W_TX_PAYLOAD) Spi.ShiftOutStr(localPtr, payloadSize) outa[SpiCsn]~~ outa[SpiCe]~~ waitcnt(1000 + cnt) ' > 10us 800 = 10 us @ 80MHz outa[SpiCe]~ ' Spin might be slow enough not to need a delay outa[SpiCsn]~ SpiWrite(W_REGISTER + TX_ADDR) ' I shouldn't need to do this. repeat localIndex from 0 to 4 ' I set this in the config method SpiWrite(txAddress[localIndex]) ' **** test to see if this still works outa[SpiCsn]~~ ' **** with address write removed outa[SpiCsn]~ SpiWrite(W_REGISTER + CONFIG) SpiWrite(byte[configPtr]) ''' this should be %00111011 this should put into PRX mode outa[SpiCsn]~~ 'Start receiving outa[SpiCe]~~I'm going to go back and add some comments.
I'm using triple " ' " marks to indicate I just added the comment.
I think most of the above code is still heavily based on Leon's C code.
As I said, this code works most of the time. I sure wish I could figure out how to preform a soft reset. Until then, I'll keep working on my add on board that uses a latching relay to reset the Nordic module.
Duane
I don't know either. I did it because Leon did it.
I wonder if there is some other trick like this to unfreezing the units. I know I can still communicate with them through the SPI link. I just don't know what else to try.
I'm not sure if I've tried transmitting a message when the unit is locked up. That would be an easier solution than adding a relay. I think I'll give a try right now.
Can you get your units to lock up by pressing the FOB buttons fast?
Duane
No, mine never locks up but sometimes I get a $1F code. I am using SPI_ASM though...
- Ron
That's one way mine will lock up. The other way is to have a bunch (I had four at once) of the Nordic modules communicating at the same time.
I think I'll go back and see if they lock up with the SPI_ASM version of the driver. This application doesn't need the speed of the faster driver.
Duane
Well, don't know about "vibration fast" but as fast as I can push them
When I have a BS2 emulating the FOB repeatedly sending the five button codes in succession at a fast rate, some "button pushes" get lost, but it never locks up.
I can't get the Nordic units to lock up with when I use SPI_Asm either.
This is huge step forward for me. Thank you very much.
I'll worry about why the other driver locks up later. Time to get back to programming. This is great!
Duane
I wrote a little driver to control the LED.
The LED I'm using is a common cathode.
Here are some of the important methods.
The "Init" method is used to define the pins.
The "FlashLed" method flashes the LED. The driver uses PWM to control the brightness of each color. The brightness level is an eight bit number (byte). The PWM frequency is about 4.3kHz. The LED is on one half of "flashTime" and off the other half. "flashTime" is in units of milliseconds.
"localCycleCount" is number of times you want the LED to be flashed. If a zero is used for this value then the LED will continue to flash until the object receives a different command.
PUB SolidLed(redByte, greenByte, blueByte, localOnTime) | localIndex, localTime, { } changeTime, largeLoopStartTime, temp[6] '' redByte how much of the on time should the red LED be on. '' greenByte how much of the on time should the green LED be on. '' blueByte how much of the on time should the blue LED be on. '' All three color numbers should be between zero and 255. '' onTime time LED is on in milliseconds. '' If onTime is set to zero then the LED will stay on '' until a different instruction is given. '' If the driving cog has not been started, this method will start the cog."SolidLed" turns on the LED for the amount of time designated by "localOnTime". Once again the units are milliseconds. If a zero is used then the LED will stay on until the object receives a different command.
The color of the LED can be changed while it is on by using the "ChangeColor" method.
The driver frequently checks the color variables in hub RAM. Either a solid or flashing LED can have its color changed using the "ChangeColor
There is an "Off" method that turn the LED off without stopping the driver cog.
I think this object will make it easier to control a red, green and blue LED.
Duane
Edit(3/11/15): Warning, the code attached is an old version. There are better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't a replacement on GitHub send me a message and I'll make sure to upload the replacement code.
I've been busy soldering all the wires needed to make multiple units.
I've added a couple of features to the RGB LED code. The code will now blink the LED between two different colors. I thought this would allow more information to be conveyed with the LED.
I thought I'd post a picture of one of the ways I'm attaching the cheap eBay Nordic modules to the QuickStart boards.
I'm actually using P0 - P5 for the modules. I moved the position of the module to allow more room on the 40-pin header for the connection to a secondary board.
The above connection has the advantage of being very easy to make. Here's a picture of the parts.
I said earlier that hardware is easy and software is hard. The problem comes when you're trying to make multiples of a prototype. It not hard to copy the software six times but building six copies of the hardware prototype can take a lot of time.
I need at least three copies before I can test all the features of these devices. I hope to have three (maybe four) units up and running today.
Duane
Did you finish this project?
Did you use the eBay Nordic modules?
How about pics of the final product and maybe code?
- Ron
late to this thread. But I thought I'd add a few comments about small
panic button type transmitters and cheap enclosures. Someone might
find the ideas useful.
I started working on a project a few months ago to create small and
very inexpensive sensors that could be placed just under the ground
and be able to send data to a cheap receiver a few hundred feet away.
I came up with some rather odd but workable ideas. First I decided to
use those really cheap crystal oscillators for the transmitters. These
are mostly used instead of crystals when working with uC's. I used a
tiny85 uC to key these small transmitters and send short data strings
back to a receiver box which contained a cheap digital radio I bought
on Ebay and a small circuit board that has a Tiny88, a tone decoder
chip (LM567) and a 3.00 USD 2 line LCD display and a small speaker
for sounding an alarm tone. This setup gives you an intrusion alarm
system that alerts you to someone approaching outside. The multiple
buried sensor devices each have a unique string of data they send back
so you know which ones have been set off.
I got the idea of what to use for the cheap enclosures for the sensors
from making tuna sandwiches in the small kitchen we have here. The
can opener works by cutting into the side of the can lid instead of the
normal way of cutting the top. This leaves you with a small can that has
a lid that fits back on the can instead of a round piece of useless sharp
scrap. This is of course nice for putting left-over tuna into the fridge. It
occurred to me that these cans with their nice lids could be used as
zero cost enclosures. What I came up with is to drill a tiny hole in the
center of the lid and one in the center of the bottom of the can. Then you
cut off a small section of small wooden dowel rod that is just slightly
shorter than the height of the can. You drill small pilot holes in the ends
of the piece of dowel and then you use a small screw to hold the dowel
in place inside the can, screwing into the dowel through the bottom of
the can. Then you can close the can by just putting the fitted lid on top
and using another screw to fasten the lid down tightly using the screw to go
through the lid and into the dowel. For weatherproofing I sealed the screw
holes and the can lid rim using a thin coat of silicone caulk...the clear
sort that never gets stiiff and hard but remains rubbery. Then I coated the
enclosure with 2 coats of gray primer paint using a spray can. If you do
not need the enclosure to be water tight then these steps can be omitted.
Inside the can is the small circuit board with a proximity sensor I thought of
and the uC. Power is from a small battery and life is long as the uC is in
sleep mode nearly all the time, waking only briefly on a schedule that can
be set using capacitive touch sensing to send data to the uC by code. A small
wire antenna exits from the can top through a tiny hole drilled on a slant
through the lid and the dowel, this serves as the cap touch sensor as well as
antenna. The unit is placed in the ground with only a thin layer of dirt covering
the can top. The antenna is insulated and protrudes a few inches above ground.
The zero cost enclosure idea and the use of those cheap oscillators as rf sources
seemed to be relevant to this thread :-)
When I was playing with this project someone remarked that the units looked
like little gray landmines..lol So I called them Land Minds since they have a
very weak mind inside consisting of the tiny85.
I should have somehow mounted a small LED through the top of the enclosure
though as it would have been easier to use when sending commands to change
the operation of the uC using the touch sensor. As it is you have to carry a small
radio to hear feedback from the oscillator being keyed by the uC....it's a pain.
The units are in power down mode where they only wake and check for input
once a minute...to wake them you have to hold them by the antenna until they
send 3 beeps to the radio and then quickly enter a code to activate them. It's
kind of cool that they have no mechanical switches of any kind, not even a power
switch was needed since in the 'power down mode' the battery lasts almost as long
as it would if it was just sitting on a shelf.
It's good to have you back. I've been wondering how you were doing on your "secret mission". Now I know you've been laying Land Minds.
I'm often looking for cheap enclosures. I like your tuna can idea.
Are these Land Minds something you can post schematics for? They sound very interesting. How is the intruder detected? Is it through the capacitance sensor you mentioned?
How do your Land Minds know to wake up? I think this stuff is beyond my current electronics knowledge especially using "cheap crystal oscillators for the transmitters".
I'm glad your back safe from your adventures.
Duane
The ideas were all mine (pun intended ;-)
The hardware I had to get help for since I have limited
electronics skills. I did the programming and a guy
I used to work with did the hardware design from my
descriptions and designed the boards. the sensor Idea
came to me from some reading I was doing on another
problem totally unrelated to this kind of thing. The idea
turned out to be pretty unique so I am keeping it quiet.
The hardware design is not mine so I don't feel free to just
post the details or board design. The program code is
nothing at all special and could be duplicated by anyone.
The tuna can idea was just a lucky notion that popped
into my head while I was making a sandwich. It also works
with cans of all sizes. You must have one of those fancy
side cutting openers though. The enclosures are really sturdy
and tightly closed once you put in the screws...and the
price is right. They sell other sorts of meat and fish in small
squarish cans that have rounded edges here. These might
make even nicer enclosures for projects but I have not tried
one since I only like tuna salad sandwiches :-)
The uC wakes up on a regular schedule and exits sleep mode
to check things and send a signal if required. It's just standard
timer stuff.
The xtal oscillators are just the cheapest rf transmitters you
can find.
I just searched ebay and found someone selling them for use
as hobby transmitters....you can get them cheaper than this
and at higher frequencies.
http://www.ebay.com/itm/6-Miniature-10-Meter-QRP-Transmitters-/350484194354?pt=LH_DefaultDomain_0&hash=item519a7c6432
If you have one of those side cutting can openers go ahead and
try making an enclosure as I described...you will be pleased.
It's a bit like the craze to use Altoids boxes as enclosures only
these are more sturdy and even cheaper since everyone opens
cans all the time...I mean, how many Altoids can a guy eat anyway.