nRF5 action!
-
@Toyman said in nRF5 Bluetooth action!:
Definitely, beyond my smd skills.
I had the same concern, but it turns out that even a clumsy solder job seems to work just fine:
I was most concerned that I might create a short, so the tombstone bridge proved to me that wouldn't happen.
-
Not sure if this thing would work, but maybe?
https://www.amazon.com/gp/product/B01B94U438/ref=od_aui_detailpages00?ie=UTF8&psc=1
-
@NeverDie This module is based on the nRF52832 and a RF AXIS PA (now purchased by Skyworks) . I happen to have one of the first prototypes. This design worked great! . Note the blue wires attached to the 32khz crystal which was later mounted on the board.. Laughing a bit here. .
-
@NeverDie I believe that the Notwired price you mentioned was for the full dev kit board with RF module.
The Octotech device is not out in the market yet. I don't think they will be making production modules. Probably will have dev kits and then looking for module manufactures to produce modules with their part. 0_1507066567924_8TR8210 Product Brief RevA3.2.pdf
-
@Jokgi said in nRF5 Bluetooth action!:
This module is based on the nRF52832 and a RF AXIS PA (now purchased by Skyworks) .
Cool! Anyone selling it now besides Aliexpress?
-
@Jokgi said in nRF5 Bluetooth action!:
I believe that the Notwired price you mentioned was for the full dev kit board with RF module.
I wish that were so, but it just doesn't look that way to me. It seems that the dev board that could go with it is sold separately, and is another $95:
https://www.notwired.co/ProductDetail/CWSEPARD-notWired-co/606027/
-
Dang, I just noticed that this board has a FEMALE ipx connector on it:
https://www.aliexpress.com/store/product/1pcs-NRF52832-Bluetooth-module-M4-kernel-Bluetooth-4-1BLE-module/2629039_32821473149.html
At least the Ebyte module has a male ipx on it, which seems much more common.
-
@NeverDie If that is the case then I kind of limits their clientele a bit.
-
@NeverDie
Exactly. There are two pads labelled SWD and SWC, originally meant for pogo pins.
I patched them with wires to the pin header.
Programming with a Chinese STLink V2 clone works flawlessly.
-
@NeverDie
What antenna did you use?
It doesn't make so much sense to replace the internal 1-2dBi Antenna with an external 2-3dBi one.
Most small WiFi antennas are simply crap.
Also, 2.4GHz is a frequency so useless, that not even the radio amateurs wanted it. They have 2.3GHz.
At 2.4GHz, you may achieve a range of kilometers if you have a free sight, but not even penetrate a single wall with the same setup.
-
@Uhrheber said in nRF5 Bluetooth action!:
@NeverDie
What antenna did you use?
It doesn't make so much sense to replace the internal 1-2dBi Antenna with an external 2-3dBi one.
Most small WiFi antennas are simply crap.
Also, 2.4GHz is a frequency so useless, that not even the radio amateurs wanted it. They have 2.3GHz.
At 2.4GHz, you may achieve a range of kilometers if you have a free sight, but not even penetrate a single wall with the same setup.I used an antenna that I temorarily removed from an ASUS router. I don't know what it's gain is supposed to be. However, I had similar thoughts, so yesterday I ordered this from amazon:
https://www.amazon.com/gp/product/B073SWWMRG/ref=od_aui_detailpages00?ie=UTF8&psc=1
which claims a 9db gain. It should arrive tomorrow. It's not really ideal, because it has to go through three connections (first the IPX connection and then an SMA connection and then finally the antenna connection), whereas it would be preferable to just have one connection so as to have less insertion loss. I'd be interested if you have any suggestions for something even better.
-
-
I want to transmit the shortest frame possible for my remote control packet, because that means the listen window on the receiver can be as short as possible, and that equals energy savings. To that end, looking at Figure 30: On-air packet layout in the datasheet (http://infocenter.nordicsemi.com/pdf/nRF52832_PS_v1.3.pdf), that would mean eliminating CRC, SO, LENGTH, S1, and the payload. What's left? Just an address. I could use one logical address to mean "ON", and a different logical address to mean "OFF".
I had already eliminated CRC from the radiohead code, and it all worked fine. Now I'm converting over to the MySensors transport code, and I'm wondering: how should I approach getting rid of those extra bytes using the MySensors transport code as the starting point?
-
I've had success in changing from sending one byte of payload to no payload at all by changing from
NRF_RADIO->PCNF0=0x80108to
NRF_RADIO->PCNF0=0x80008However, so far I haven't been able to shed S0 and/or S1 and still get the packet received, even if there's no payload.
Interestingly enough, the smaller frame works better than the more bloated frame. I guess less chances for it to get corrupted over the air.
-
@NeverDie said in nRF5 Bluetooth action!:
@d00616
I want to transmit the shortest frame possible for my remote control packet, because that means the listen window on the receiver can be as short as possible, and that equals energy savings.I think the best way to do this is using the Bit counter. Set a timer to stop the radio and with the bitcounter, you can stop this timer. With the BC, you don't loose the CRC or length information. The Bit counter counts the S0/S1 and Length information and all data bits.
I use the bitcounter in the ESB-TX mode.
-
Since it appears now that there's no way to avoid sending S0, LENGTH, and S1 over-the-air in the course of a full packet transmission cycle (even if their values are zero), I'm having success using EVENTS_ADDRESS to remove them from the equation anyway by cutting short the full packet sending/receiving process just after the address is either sent or received.
-
@NeverDie said in nRF5 Bluetooth action!:
I received the following message from the Ebyte seller:
Sorry that the two files are incorrect, please just ignore or delete them. We will send correct files later. Thank you!Hi, they sent you the right files? Can you share them?
Thank you very much, great discussion
-
@maniron
They never sent them. Would you be willing to try asking them too? Maybe if enough people do, they'll finally take some action.Unrelated, but I notice they've raised their prices.
-
OK, so I've reduced the over-the-air transmission to one preamble byte and 5 address bytes, for a total of six bytes. The transmitter sends a packet to a different logical address depending on which button is pressed, and the receiver can determine which button was pressed depending on which logical address matches.
So far, so good. The question now will be how many of those bytes I can eliminate before I start to get garbage packets.
The other factor is the granularity of the RTC. The receive window will either be about 30us or 60us, and I believe (but haven't yet confirmed) that I'm already at around 60us. So, I may already be at the practical limit.
-
@NeverDie I would not go less then 3 address bytes or random noise may look like valid addresses. The more address Bytes the less chance of that happening.
-
@d00616 You may wish to count your retries as well. It is no use keeping the window narrow if you need to keep transmitting and receiving to get the same packet across. It may show that having a little wider window reduces the average current required by increasing the chance of picking up the packet first time. If you are using a timer to synchronize the RX and TX (TDMA) then you may be just fine.
-
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie I would not go less then 3 address bytes or random noise may look like valid addresses. The more address Bytes the less chance of that happening.
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie I would not go less then 3 address bytes or random noise may look like valid addresses. The more address Bytes the less chance of that happening.
According to the datasheet, it appears to force a minimum of 3 address bytes anyway: 2 base address bytes plus 1 prefix address byte. With no prefix byte, it would appear that's as low as the hardware will allow.
-
@NeverDie I would not use a 2byte address for the reason I gave above. I was not including the preamble which is not really part of the address. 3 byte minimum is what I would recommend, not 2.
-
I can't make sense of the Packet configuration register 1 (PCNF1). Upon powering up, its value reads 0x262164, which doesn't really make any sense. I then try changing it to 0x22164. When i re-read it though, its value is then 0x139620, which is completely different. And this is 100% repeatable.I can't make sense of this. What's going on with PCNF1? Why doesn't it keep the value that I set it to? why does it rapidly change over to the other number, and why that number in particular? I've tried setting it to other numbers also, but each time it doesn't stick and instead produces a puzzling number in its place. I've even confirmed that the radio is in a DISABLED state prior to making the change, but that doesn't seem to help either.[Edit: mystery solved. I was accidently printing it as decimal instead of HEX. So, it works perfectly after all. :)].
.
-
Setting aside that mystery for the moment, the remote control presently is working very well, and the current draw during listen mode is now down to this:
which is certainly less than previously. Scale: 1mv=1ma.It turns out that there's a minimum of 1 preamble byte. So, all told, there is a minimum of 4 bytes total that have to be transmitted: 1 preamble, 2 base address, 1 address prefix.
Eyeballing it, it does look as though the actual window of active listening is already around 30us, and unfortunately the granularity of the RTC prevents me from making it smaller than that. So, I suspect that, regarding power draw, this is already as good as it's possible to get.
-
@NeverDie I would use 3 ADDRESS bytes, for the reason I gave before. The receiver could see noise as a valid packet and try to process it. and the fact you have no data packet and no CRC could cause you issues in a noisy 2.4Ghz environment. . Also be aware that if the radio is not already in receive or transmit mode the PLL takes about 130us to come up and settle. Crystal start and settle time will also depend on the CL value of the Crystal and not all manufactures use the same value. Conversely you can only transmit packets for 4ms before you need to bring down the transmitter and bring it back up again for the PLL to start and settle.
-
@Jokgi said in nRF5 Bluetooth action!:
Conversely you can only transmit packets for 4ms before you need to bring down the transmitter and bring it back up again for the PLL to start and settle.
Is that true for the nRF52832 as well? I had read it was true of the nRF24L01+, which is what led me to set it aside and go full bore on the nRF52832 instead.
-
@NeverDie Good catch!! The nRF52 series does not have this "feature". In other words, you don't have to bring the transmitter down to recalibrate the PLL..
Only nRF51 and nRF24xx and nRF24L series legacy devices require it.
-
@Nca78 said in nRF5 Bluetooth action!:
so I replaced it with a 0603 of the same capacity.
Uh, what exactly is that capacitor value? I just had the same thing happen to me!
-
@NeverDie the nRF52 pll comes up in about 40us....
-
I received this from Amazon today and hooked an Ebyte nRF52832 (with the switched capacitor) into it:
https://www.amazon.com/gp/product/B01B94U438/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1It actually does extend range. Not as well as I had hoped, but better than this high gain antenna, which I also received today and which, in comparison, I would call little better than a placebo:
https://www.amazon.com/gp/product/B073SWWMRG/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1Soooo... With the bad news just received about the nRF51 (above) being limited to 4ms of Tx time at a time.... I guess it's time for this as Plan B on an nRF52832 gateway. Unless someone has a better idea. What I do like about it, given that it is a bolt-on, is that it senses when the nRF52832 begins to transmit, and only switches on the PA then. The rest of the time its in receive mode.
-
@Jokgi said in nRF5 Bluetooth action!:
Also be aware that if the radio is not already in receive or transmit mode the PLL takes about 130us to come up and settle.
Actually, maybe that's not so bad after all. So after Txing an nRF51 for up to 4ms, I can DISABLE it (which takes how long?), and then be back up for TXing for another 4ms after about 130us? If so, that's not as bad as I had feared.
-
@NeverDie said in nRF5 Bluetooth action!:
@Nca78 said in nRF5 Bluetooth action!:
so I replaced it with a 0603 of the same capacity.
Uh, what exactly is that capacitor value? I just had the same thing happen to me!
Sorry I did that on a NRF24 modules.
I tried to measure on my nrf52832 module but didn't manage, I've got out of range measurement in capacitor measurement mode, and in "scan" mode it's detecting it as a resistor with 0.9 Ohms value...
-
The passive part for switching between antennas is a 0ohm resistor I think. Depends on the circuit, but it makes sense (I designed a few boards with pcb ant + uFl, and I do the same).
I bought this antenna a while ago, for testing/tuning purposes..
(in case, I have not yet compared range vs others antenna
)
Looks the same as @NeverDie ordered, except this one is wideband 700 to 2600Mhz which is pretty coolhttps://www.passion-radio.com/gb/wide-band/umts-magnetic-314.html
-
@scalz Wideband means: Bulky, but nevertheless low gain.
With "low gain" as in: performs as well as a piece of wire of 1/4 wavelength.
-
@Uhrheber
i'm using it in a simple way, with rtl-sdr, and for its versatility.
they say 9dB, but I don't really mind about that. It would not change anything to connect it for increasing range of 4db nrf52.
I'm just interested in the overall quality, as it's mostly for receiving with rtl, and doing checks etc.
I'm also planning to test other types of antenna, and build one for discovery.It's not for my HA network, of course it would be too bulky
-
@NeverDie said in nRF5 Bluetooth action!:
It actually does extend range. Not as well as I had hoped, but better than this high gain antenna, which I also received today and which, in comparison, I would call little better than a placebo:
https://www.amazon.com/gp/product/B073SWWMRG/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1Those 2.4GHz pseudo stocked dipole antennas have always been crap.
Even if they had 9dBi, they'd lose most of it because of the thin lossy cables.
Never combine a high gain antenna with a long cheap cable, it's a waste of money.Most better patch antennas work quite well, as do parabolic and backfire types.
I have a 16dBi patch antenna, that works amazingly well. I can, from inside the house, see WiFi APs that are kilometers away.If you're on a budget, build a cantenna. If not, buy a not too cheap patch antenna.
-
@scalz For rtlsdr, I once bought one of those (outdoor) scanner antennas, that claim to be usable from 20MHz to 2GHz, only to find out, that a simple coat hanger antenna made from coax performs ways better.
I can even receive the NOAA satellites with it.
-
@scalz said in nRF5 Bluetooth action!:
The passive part for switching between antennas is a 0ohm resistor I think.
Thanks! That would make all the difference, because it will be a lot easier to solder bridge the new connection than it is to re-position an itty-bitty cap.
-
@Uhrheber said in nRF5 Bluetooth action!:
I have a 16dBi patch antenna, that works amazingly well. I can, from inside the house, see WiFi APs that are kilometers away.
Do you have a link to the one you purchased? Rather than rolling the dice again, I'd rather get something that's "known good".
-
@Uhrheber said in nRF5 Bluetooth action!:
Those 2.4GHz pseudo stocked dipole antennas have always been crap.
Even if they had 9dBi, they'd lose most of it because of the thin lossy cables.
Never combine a high gain antenna with a long cheap cable, it's a waste of money.Has anyone found a source for good quality pre-made cables with the connectors already attached? Again, I'd prefer to buy a "known good" product from a known good source than to keep rolling the dice.
-
Here's something which seems odd: I removed the bridge resistor from the Ebyte nRF52832, so that there was no soldered connection left. Then I checked it with my continuity meter, and they show connected anyway! Not really believing it, I tried it on a second module also, with the same result.
So, this means that the trace which is intended to go to the antenna is already connected to ground. Should it be? It doesn't seem right to me, but then I'm no expert.
Anyone?
-
By the way, from reading the instructions which came with the 4w booster, the recommended power input into it is between 7dbm and 20dbm. Obviously, the nRF52832 is 4dbm maximum, so this probably explains why the product is not excellent in this configuration. Bottom line: I don't think it's the solution.
-
@NeverDie from what I see in the picture of this module, it is using a Meandering Inverted F antenna. Part of that antenna is connected to ground. So you will measure a DC ground from anywhere along the antenna to ground.0_1507315872619_Ember -inverted F_120-5052-000_Designing_with_a_PCB_Antenna.pdf
-
Finally found some nRF52832 modules with a PA that doesn't require a minimum order of 5 units:
-
@NeverDie Is there a schematic available?
-
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie Is there a schematic available?
Not that I've seen, but there is this, which has a bit more info: https://www.aliexpress.com/store/product/PTR9618PA-Nordic-nRF52832-Module-PA-module-BLE-4-0-Module-Free-shipping/130096_32758834433.html
Taken at face value, it seems to imply that the unit includes DCDC regulation, that it does not include an external low frequency oscillator, and that pin P0.24 is used to enable/disable the PA.
-
@NeverDie The datasheet is here: http://www.freqchina.com/plus/view.php?aid=1083
(Click on the "Data" tab.)
-
@NeverDie
I bought it used on ebay, for little money.
But generally you can assume that everything that comes with an N connector is meant for (semi-) professional use.Conversely, avoid everything that comes with a reverse-SMA connector and/or a thin cable.
It's usually crap.
-
@Uhrheber said in nRF5 Bluetooth action!:
@NeverDie The datasheet is here: http://www.freqchina.com/plus/view.php?aid=1083
(Click on the "Data" tab.)
Thanks! Just in time too, as it looks as though pin P0.20 is reserved also.
I just now did a breakout board for it. If anyone is interested in it, I can post it.
-
Plugged my NRF51822 board into a cr2032 button battery and it is sending voltage/Rssi/Random Temperature every 1min.
Just to see how low it goes and how long.
I also changed my controller over to Grafana and influxdb/Node-red.
So far i am suitably impressed.
-
What are you using as the "controller" then? Is it Node Red? The other two aren't listed on the Mysensors controller page.
-
@Uhrheber said in nRF5 Bluetooth action!:
Conversely, avoid everything that comes with a reverse-SMA connector and/or a thin cable.
It's usually crap.I changed the connection from the nRF52832 to the 4w booster over to this:
https://www.amazon.com/gp/product/B06WGY8FJB/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1
and it was an improvement. I can't help but wonder now whether an even thicker cable would work even better? What's a good source for getting even better (and thicker) cabling solutions of this type?
-
@NeverDie
Yes Node-red is the controller which is saving data into influxdb and then displaying the data in grafana.
But i am also using the node-red dashboard for any actuator nodes etc as grafana is really just for viewing the data.
-
@NeverDie It isn't possible to crimp a thicker wire to a U.FL connector.
Therefore you have to use a thin cable, but keep it as short as possible.
There are thin cables with lower loss, but they tend to be very expensive.
-
@NeverDie For a development board, it could be interesting to drive LEDs with P0.20 and P0.24, because they'll show you exactly when the board sends or receives.
-
What about "long-range" iBeacons like Skylab or RedBear ones? Do they have some kind of PA or their "long-range" is just a marketing gimmick?
-
Hi Guys,
Since this topic passed the 1000 posts, can someone tell me if the NRF5* , for mysensors, is worth diving into?
And could someone be so kind, to sum up some pro/cons?
Would be much appreciated since I wasn't able to follow since post 400.
-
@Omemanti this thread has very litte information related to MySensors, so you haven't missed much on that topic.
https://forum.mysensors.org/topic/6705/mysensors-nrf5-platform is better for MySensors-related stuff. But the summary is that you'll need to be prepared to do troubleshooting and maybe also some coding. Some things are known broken, and a lot of things are not well tested.
On the other hand, nrf5* is an interesting solution, and real-world testing would be very valuable for making the MySensors support better.
-
I think when the nRF52840 gets released and made widely available, most people will eventually want it. It's a game changer. Right now it's early adopters with the nRF52832 and nRF51822, but even those offer smaller size, better range, much faster computation, and better radio power consumption.
-
@NeverDie @mfalkvidd : Thnx!,,
@NeverDie ; what do you mean with gamechanger? a completely new standard? will it be able to talk with the nrf24 like the nrf52382, of do you need to start all over again with a blank sheet?
-
@Omemanti
Not sure I can explain it beyond pointing to the much longer range of the 840 together with gobs of memory. Each node could be its own webserver, for instance. Having been exposed to the nRF52832, I have no desire to go back to the old ways of doing things. Even PPI is a very powerful tool that just doesn't exist in the old architecture.
-
@NeverDie
So you would drop the NRF5382 for a 840?
-
I don't think it will be either/or. It will be both. Pricing will probably favor the 52832. I'm even intrigued by the 51822, because you can buy it on a breakout for around $2.50, and it's very small, complete with a very small pcb antenna. I mean, where else can you find a complete system for that little money on such a small size? You can fit it in practically anywhere.
-
I'm not neutral ;-). I have ported MySensors to the NRF5 platform and completely reimplemented the NRF24 protocol, because at the point of starting Nordics License for the ESB protocol was not compatible with Open Source Licenses.
@Omemanti said in nRF5 Bluetooth action!:
Since this topic passed the 1000 posts, can someone tell me if the NRF5* , for mysensors, is worth diving into?
I you are able to do more than described in the MySensors example sketches, you should give it a try. It's a little bit more complicated than starting with ATMEGA based boards.
And could someone be so kind, to sum up some pro/cons?
Pros:
- Enough Flash and RAM
- Faster CPU
- periphery can do a lot of things while the CPU is sleeping (PPI, SHORTS)
- Small footprint of sensors
- Mostly free pin mapping in your Sketch
- NRF24 compatible
- Same price like ATMEGA + NRF24
- No bad clones like NRF24
- Better range than NRF24 (
- Flexibility to change the radio protocol
- BLE Long range, USB with the upcomming NRF52840
- Most complete 32 Bit implementation for MySensors (at the moment) supporting sleep(), hardware random numbers, soft signing and an internal EEPROM emulation without additional hardware.
- Great hardware included
- Can be mixed with other radio modules like NRF24 (useless but tested) or RFM (untested)
- Enough resources for better security concepts
- No need for ATSHA204 when you don't require read back protection. Enabling read back protection depends on OTA updates, which are not implemented at the moment.
- Well documented MCU's
Cons:
- Not all Arduino functionality available like EEPROM (available in MySensors or externaly via emulation), Tone library
- Maybe some bugs in the arduino implementation or radio implementation
- OTA firmware update is missing for MySensors, but it's possible
- BLE with MySensors is not supported/tested at the moment. I think BLE support needs a little bit of porting code to SoftDevice API
- Beta: Needs field testing
- Multiple NRF5 Arduino ports like (arduino-NRF5 or Primo). Only arduino-nrf5 without SoftDevice is supported at the moment.
Neutral:
- Radio is for 2.4GHz only which means less regulations but shorter transmit distance
- The NRF24 protocol isn't a good protocol for encryption or battery powered nodes permanently listening for packages, the protocol can be replaced in 100% NRF5 networks in the future
I think there is no future for 8 Bit Controllers in the Arduino world. If you want to do more without diving into the PROGMEM hell, then it's time to switch to 32 bit controllers. The NRF5 is an interesting and highly integrated choice for 2.4GHz networks.
My small home network is completely NRF5 based. From time to time a node stops receiving packages. The problem is known and documented by Nordic. I working on a fix.
There are some differences in timing between NRF24 and NRF5 which are no problem, I think. The NRF24 is ~12µs earlier in RX mode and the NRF5 is ~400µS earlier in TX mode. If this is a problem, it's catched by a retransmit. Instead of tuning this protocol, I think it's better to invest the time in creating a protocol which allows battery powered nodes to listen for packages and allowing better security than the NRF24 ESB protocol.
-
@NeverDie Check out the new nRF52810. It is a stripped down version of the nRF52840.. Not as much memory and the peripherals are lower in count. But it has a Cortex M4 (Not F) and some of the targets are sensors, wearable, beacons, etc. On air compatible with nRF24L series and nRF52 series. Some limitations on BT 5.0 however.
-
@d00616 & @NeverDie
Thnx, this saved me hours
Will dig into the NRF52832. Already got some Ebyte module's and some other thingies to sort out.
It was eaghter dig into the NRF52832 or give the NRF24 another chance. NRF5* it is.Thnx so far!
-
I posted the files for a remote control based on the power amplified nRF52832:
https://www.openhardware.io/view/482
-
@NeverDie Please read post in "Harvey Rainmaker" thread about Nordic class in Austin.
https://forum.mysensors.org/topic/7403/harvey-the-rainmaker/11
-
@Omemanti said in nRF5 Bluetooth action!:
@NeverDie ; what do you mean with gamechanger?
Oh, and let's not forget the Bluetooth 5 capabilities of these chips, which I expect will allow the leverage of a lot of other bluetooth devices. Despite the title of this thread, we've barely even scratched the surface on that topic (yet). I'm looking forward to it.
-
@NeverDie The really nice thing about the nRF52832 and other nRF52 variants is that running the BTLE stack (Softdevice ) you can run BTLE and proprietary somewhat simultaneously. You choose where you want to have them running this. Each node or just one for Smart Device connectivity.
-
@NeverDie said in nRF5 Bluetooth action!:
you can buy it on a breakout for around $2.50
do you have an example? The lowest I can find is ca. $4 (incl.S&H).
Don't get me wrong, $4 is more then adequate for 328+24L01 replacement, but $2.5 is even better :-)))
-
@d00616 absolutely excellent summary, thank you.We definitelly needed some kind of "what do we know so far"
Is it confirmed that the range and power consumption are on par with 328+24L01 combo? I don't mean any "scientific" proof, but something like "I have placed nrf52 node at the same location in my house as nrf24 node and had no issues"
I am awaiting components to make "u-current meter" and test current consumption by myself
-
@Toyman said in nRF5 Bluetooth action!:
do you have an example? The lowest I can find is ca. $4 (incl.S&H).
Don't get me wrong, $4 is more then adequate for 328+24L01 replacement, but $2.5 is even better :-)))Type nrf51822-04 in AliExpress search bar, you will find the cheapest module. Not many pins broken out because it's supposed to be used as a Bluetooth interface, but it's enough for many applications like door sensor, switches, etc etc
https://www.aliexpress.com/item/NRF51822-04-BLE4-0-Wireless-Bluetooth-Module-TTL-Low-Power-Consumption-3-3V-New/32821044213.html
-
@Nca78 cool, thx
-
@Toyman said in nRF5 Bluetooth action!:
Is it confirmed that the range and power consumption are on par with 328+24L01 combo?
Yes, it's better in both dimensions.
-
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie Check out the new nRF52810. It is a stripped down version of the nRF52840.. Not as much memory and the peripherals are lower in count. But it has a Cortex M4 (Not F) and some of the targets are sensors, wearable, beacons, etc. On air compatible with nRF24L series and nRF52 series. Some limitations on BT 5.0 however.
Where are the long range BLE modes? I think long range BLE modes are one of the best features of the 840 series.
-
@d00616 not supported by 52810
-
@Nca78
I just now posted a small breakout board for it: https://www.openhardware.io/view/483
-
What's the proper way to deal with interrupts on nrf?
Many white areas:- shall I use "smartsleep()" instead of usual arduino way of attaching interrupts? is it enough?
- what pins have hardware interrupts? any?
- what about the macro mentioned in d00016 readme?
- how to overcome nrf51 bug of 1ma power consumption (code-wise)? Otherwise I see no reason buying nrf51 modules if they consume 1ma while sleeping
I thoroughly read al the docs before asking!
-
@Toyman said in nRF5 Bluetooth action!:
What's the proper way to deal with interrupts on nrf?
Welcome to the bleeding edge. I'm only aware of the one way, which is how @d00616 does it in his example code above. It seems like this part of the code is still (?) under development. For instance, the HW supports multiple interrupts being active at the same time, whereas the current code seems to support at most one interrupt.
-
@NeverDie wait, d00616 code is basically an extension of Sandeep's. The Sandeep's code (should) supports 8 interupts for nrf52 and 4 - for nrf51.
At least, that's what I conclude from here
Assuming it works, the next question is: can I put just ANY pin into attachinterrupt() function or not?
-
I made this adapter to aid with collecting serial debug output from the last two nRF5 breakout boards:
https://www.openhardware.io/view/484/IDC-10-pin-ARM-debug-adapter
-
@Toyman said in nRF5 Bluetooth action!:
What's the proper way to deal with interrupts on nrf?
Many white areas:what pins have hardware interrupts? any?
There is an limit in the number of monitored pins but not which pins are monitored.
what about the macro mentioned in d00016 readme?
This macro is required on NRF52 to read back event registers in interrupts. This clears the cache.
how to overcome nrf51 bug of 1ma power consumption (code-wise)?
Otherwise I see no reason buying nrf51 modules if they consume 1ma while sleepingThis depends on the nRF51 chip release. The first available chip release has this type of bug. I prefer nRF52 because the chip is much more flexible with better radio characteristics.
The flexibility of nRF5 MCUs starts with the interrupt vector in RAM. This allows to add bootloaders without adding latency or you can replace interrupts which are predefined in the arduino-nrf5 software.
-
@d00616 said in nRF5 Bluetooth action!:
The first available chip release has this type of bug.
So, it's a hardware bug then? i.e. nothing can really be done about it for that chip release?
-
@NeverDie said in nRF5 Bluetooth action!:
@d00616 said in nRF5 Bluetooth action!:
The first available chip release has this type of bug.
So, it's a hardware bug then? i.e. nothing can really be done about it for that chip release?
There is a second method via GPIO -> pin sense for interrupt detection. This method requires less power, but you have to detect which pin is changed in software. Simulating a pin change interrupt is more complicated as detecting high or low level. I have started to do some researches and tests, but in my opinion it's to much work to support these outdated chip variants.
-
Motivated by the above, I just now did some current tests on the nRF52832 and found that:
- Going directly to an RTC sleep after powerup consumes 2.2ua.
- Enabling DCDC doesn't increase that.
- Nor does blinking an LED and then putting that pin into a disconnected state (D0) before sleep.
HOWEVER,
4. Activating Serial using Serial.begin(..) before sleep causes the current drain during sleep to rise to around 10.8ua. That was surprising to me, because this code in hwSleep(..) seems geared toward turning OFF serial prior to sleep:// Idle serial device NRF_UART0->TASKS_STOPRX = 1; NRF_UART0->TASKS_STOPTX = 1; NRF_UART0->TASKS_SUSPEND = 1;So, I guess more is needed there?
-
@d00616 thx. How do I use the macro? Just put in ISR?
Regarding the bug: if read the docs correctly, all nrf51 have the bug
-
@NeverDie do you use hwSleep() instead of sleep()?
-
-
OK, I found that adding:
NRF_UART0->ENABLE=0; //disable UART0brings the current consumption back down to 2.2ua during sleep.
-
@NeverDie should it be placed just before hwSleep()?
-
@Toyman said in nRF5 Bluetooth action!:
@NeverDie should it be placed just before hwSleep()?
It's just a possible preliminary piece of the solution, because you'll need to renable UART0 after waking up from sleep. I haven't tested to see whether Serial.print(..) still works after re-enabling, or whether it needs to be re-initialized. Those are details yet to be sorted.
Or, maybe there's some other way of doing it. At this point, I'm just reporting my finding and tossing it out there as a tantalizing possibility.
-
@Toyman said in nRF5 Bluetooth action!:
@d00616 thx. How do I use the macro? Just put in ISR?
Yes. Give the event register as parameter.
Regarding the bug: if read the docs correctly, all nrf51 have the bug
This bug is listed as PAN#39 and fixed at the end of 2014.
-
@NeverDie said in nRF5 Bluetooth action!:
OK, I found that adding:
NRF_UART0->ENABLE=0; //disable UART0brings the current consumption back down to 2.2ua during sleep.
Great work. Are you able to build an Pull Request fixing this? This Pull request should also be tested in the condition with a disabled serial port.
If you need help, please ask. I do the reviews.
-
@d00616 said in nRF5 Bluetooth action!:
Yes. Give the event register as parameter.
so, if I have an intterupt atached to pin 1, what shall i put into ISR?
NRF_RESET_EVENT....;
Sorry for dumb questions, this is completely new to me.
-
@d00616 said in nRF5 Bluetooth action!:
If you need help, please ask.
What is it that I submit? A diff file or something? And I'm guessing I do it through github?
-
Just re-enabling the UART isn't enough. Nor are the existing UART related instructions after a wake-up, if UART0 was disabled. It seems to require a re-initialization. Another Serial.begin(BAUDRATE) after wake-up does work. However, I should point out that doing that isn't free, as it adds to wake-up time. So, you may wish to add another "level" of sleep, one which saves more energy while sleeping but at the cost of a longer wake-up. Moreover, the energy consumed during the longer wakeup isn't free either, so if the sleeps are very short, you could lose more energy for using it than not. One may, therefore, also want to calculate the breakeven point to provide guidance on when to use which level of sleep.
In short, this is more than a simple fix, and the software architect probably needs to consider the bigger picture in order to craft the best solution.
-
-
@Toyman said in nRF5 Bluetooth action!:
Guys,
Have you seen this?
Note, that our beloved ebyte is not there, but PTR9618PA is
It's useful. But just knowing the module exists is one thing. Finding a source for it is another.
Suggested Topics
-
Welcome
Announcements • • hek
