nRF5 action!
-
@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.
-
@NeverDie I believe, buying non-Chinese modules in retail is virtually impossible, but Xuntong, Skylab and Raytaq are available at Ali.
For me, the list is more like "quality assurance"
-
@Toyman said in nRF5 Bluetooth action!:
@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?
With arduino-nrf5, you can't put nothing into the pin interrupt ISR because the ISR is already defined.
Sorry for dumb questions, this is completely new to me.
There are no dumb questions, there are bad answers.
-
@NeverDie said in nRF5 Bluetooth action!:
@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?
There is and document describing the procedure: https://www.mysensors.org/download/contributing
I think this is a good document to start with. If you have trouble, please ask.
-
@d00616
The solution I'm going with, which serves my present needs, is just to put all serial communications code within "DEBUG" compiler directives. So, if I'm not debugging, the issue just goes away, and there's no added overhead.
-
@NeverDie said in nRF5 Bluetooth action!:
@d00616
The solution I'm going with, which serves my present needs, is just to put all serial communications code within "DEBUG" compiler directives. So, if I'm not debugging, the issue just goes away, and there's no added overhead.Found a shortcut. Instead of doing all that, which is extra work and looks ugly too, I just disabled the UART0 on the first sleep, and then never re-enabled it. It works.Now my sleep current is just 2.1ua, except for the brief pulses every 100ms where the PPI listens for an incoming packet addressed to it.
-
I was just checking the nRF51 datasheet, and I don't see much, if any, PPI control available. So, I suppose that's yet another reason for preferring the nRF52....
-
Nonetheless, I just now measured the sleep current on the cheap nRF51822 that @NCA78 referenced:
https://www.aliexpress.com/item/NRF51822-04-BLE4-0-Wireless-Bluetooth-Module-TTL-Low-Power-Consumption-3-3V-New/32821044213.html?aff_platform=aaf&cpt=1507850033284&sk=e2Vzr3v&aff_trace_key=fa8ec197f200446fbd58fc8679ffb3bd-1507850033284-07709-e2Vzr3v&terminal_id=29bfb7ff18284b7f96acb3c3884390ce
It measures at 5ua, which is higher than the 2.1ua of the nRF52832, but still not bad in absolute terms. I was afraid after the discussion of how some nrf51's had a 1ma bug in the hardware that they would be counted among them. Fortunately, it seems not.
-
@NeverDie The nRF51 is done on a different process then then the nRF52. The nRF52 is on average 50% lower power then the nRF51. The picture of the module shows a nRF51822QFAA Hx part which is a 256k flash, 16k Ram part REV 3. You can see all the revision number here: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf51/dita/nrf51/compatibility_matrix/nRF51822_ic_revision_overview.html?cp=3_0_1
-
@NeverDie You may wish to check out the nRF51 Reference guide in addition to the datasheet. http://infocenter.nordicsemi.com/pdf/nRF51_RM_v3.0.1.pdf The PPI is located in section 16.
-
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie You may wish to check out the nRF51 Reference guide in addition to the datasheet. http://infocenter.nordicsemi.com/pdf/nRF51_RM_v3.0.1.pdf The PPI is located in section 16.
Thanks! Doesn't look as though the nRF51822's PPI allows for FORK though, whereas the nRF52832 does.
-
@NeverDie actually, I am suprised that many of these modules are available and at the prices lower than Ali.
For example:
http://www.fanstel.com/buy/bt832xe
They claim "BT832XE is the longest range Bluetooth 5 module, 1350 meters between 2 BT832XE with used with ANT060 antenna."
$23, shipped within US
Not bad, ah?
-
One must be aware, that the gain of an antenna doesn't come from a magic amplification, but from direction.
Meaning, the higher the gain of an antenna is, the more directional it is.
For a sensor, let's say a window switch, that may end up in every mounting position you might imagine, this is NOT what you want.Neither do you want that for the gateway, that may be in the middle of the house, and should be able to receive transmissions from all directions.
-
@Uhrheber
It does look like they also have a PA on their module: http://www.fanstel.com/bt832x-bluetooth-5-module/It's a good find, as it looks as though they have a lot to choose from: http://www.fanstel.com/buy/
Also, as compared to the chinese vendors, I think it's more likely that they really did pass FCC, since it's based in the US. The fines to US companies for selling non-compliant stuff are pretty severe (enough to bankrupt a small company), whereas (it seems) the chinese vendors can dodge it. Hence, the joke that "CE" stands for "Chinese Exemption".
-
@NeverDie exactly! On top, they have very extensive datasheet with all the results
-
I just now noticed that fanstel is selling an nRF52840 module: http://www.fanstel.com/buy/bt840f-v1-nrf52840-bluetooth-5-thread-zigbee-module
That's the first I've seen on the open market (aside from the DK that is). [Edit: won't be shipping until January though]
I wonder which, if any, of the Fanstel modules contain the DCDC hardware? Their pinout on the 832's does not appear to be as complete as the Ebyte module, so if DCDC is not already on the module, it might be impossible to add after-the-fact.
-
@NeverDie said in nRF5 Bluetooth action!:
Their pinout on the 832's does not appear to be as complete as the Ebyte module, so if DCDC is not already on the module, it might be impossible to add after-the-fact.
Page 13,
pin F5
-
@Toyman Thanks! I'm going to order a couple of the Nordic nRF52840 PDK's to audition now that modules are on the horizon. Shall be interesting to see how the range compares in a normal home environment. Also, 256K RAM and 1M of flash sounds like such a luxury!
-
@NeverDie Note that all the nRF52840 based products being showcased now (including the Fanstel modules) are using the engineering silicon. There is Errata on these parts. Production devices will be available Q1-18.
-
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie Note that all the nRF52840 based products being showcased now (including the Fanstel modules) are using the engineering silicon. There is Errata on these parts. Production devices will be available Q1-18.
Do you advise waiting, or is it sufficiently non-buggy that it's likely to work unless doing something obscure?
-
@d00616 Problem #1 is that there does not yet appear to be an Arduino board definition for the nR5F2840, as there is already for the nRF52832 and nRF51822. Is that correct? Or does one already exist somewhere? It's critical path to testing code on the nRF52840 PDK.
-
Hmmm... Looks like there is an nRF52840 "variant": https://github.com/lpercifield/arduino-nRF5/commit/d55d54a1bdc479acc259e131f0f445c5da8e02b3
Would that work? If so, how exactly should it be added so that it will appear in the Arduino IDE board manager list of boards?
-
@NeverDie the main issue it's "65 commits behind master" so it's outdated in all areas except 840
Theoretical path is to make a fork of current sandeep's branch and then merge the changes from the repository you found. But given the above, it won't be easy.
-
Gosh, I'm wishing now that I hadn't ordered the PDK. I guess I'll just return it for a refund. Since it sounds like literally no one else is presently using the 840, I'd rather move forward on the 832. I'm more interested in the 2mbps datarate anyway (for the reason below). And I'm pretty sure PA versions of the nRF52832 will beat the range of an unamplified nRF52840.
-
@d00616 said in nRF5 Bluetooth action!:
Great job. If I'm not wrong the method allows nearly 1 year of listening time with a CR2032.
Yup, based on the latest measurements, I estimate an average current drain of about 25 microamps. So, assuming a CR2032 has 240mah of useable current, that comes out to about 1.1 years of listening time. Or more than 13 years on a pair of Energizer Lithium AA's. Pretty cool.
And that's listening for a packet once every 100ms. It could last much longer if it were to listen less often.
-
@NeverDie said in nRF5 Bluetooth action!:
Gosh, I'm wishing now that I hadn't ordered the PDK. I guess I'll just return it for a refund. Since it sounds like literally no one else is presently using the 840, I'd rather move forward on the 832. I'm more interested in the 2mbps datarate anyway (for the reason below). And I'm pretty sure PA versions of the nRF52832 will beat the range of an unamplified nRF52840.
I looked at the fanstel modules a while ago, but like guys said above, these are beta mcus with errata. And not arduino uptodate for the same reason i guess.
I have one 840pdk too. for tests
with apache mynewt. Because I have only one 840 board I can't tell you about the range because it needs two boards for checking that, two boards with full BLE5 Long range (and 832 is not BLE5 full range).No idea about 840 vs 832+PA but 840 is already PA integrated which is pretty cool. It also has some other nice features. Range tests regarding BLE5 long range are impressive imho, indoor or not, and from different mcu manufacturers (some have nice parts).
I'm not sure though, if 840, is compatible with NRF24. And, as I'm talking about BLE, I prefer to say it again, for others.. BLE is not MySensors
-
Are there any examples of how to control the potential BLE5 capabilities of this chip using code developed in the Arduino IDE? I recognize that it's presently a separate thing from MySensors, which is using the proprietary modes to ensure backward compatability to the nRF24, but surely getting some hooks into BLE5--even if it's just high level stuff--would be beneficial wouldn't it?
-
For instance, how hard would it be to create a simple serial bridge so view serial output on your bluetooth phone, the way @sundberg84 is doing with a specialized bluetooth module: https://forum.mysensors.org/topic/6340/debug-to-a-sd-card-module
-
@NeverDie said in nRF5 Bluetooth action!:
For instance, how hard would it be to create a simple serial bridge so view serial output on your bluetooth phone, the way @sundberg84 is doing with a specialized bluetooth module: https://forum.mysensors.org/topic/6340/debug-to-a-sd-card-module
For similar functionality, there is an MY_DEBUG_OTA feature in MySensors development branch. You can send log messages to any node in the MySensors network.
The NRF5 MySensors port is running directly on the MCU hardware. Using the SoftDevice is like running an Operating System. There are limitations using the Hardware and APIs have to use. You are loosing control over the Radio, some Timers and RTC, Crypto components and the memory layout.
The reason the SoftDevice isn't supported is the old licence model. This model is changed with SDK14.
In my opinion with MySensors 2.x it isn't meaningful to play with the multiplexing of the radio module. I think this requires more changes in MySensors to handle the time when the MCU is in BLE mode.
If you are interested implementing a dual stack software, then I think the Arduino Primo port is a good point to start. This is based on the NRF5 SDK. The Primo port has no support for NRF51 devices.
If you are not restricted to Arduino, you can also see MyNewt or Zephyr. Both have BLE Open Sorurce implementations for the NRF5 MCUs.
-
I agree with @d00616 points above.
And, sure bluetooth would be nice for interacting or debugging.In my opinion, maybe I'm wrong, for my network, I would prefer MySensors NRF ESB, in general.
- "more secure" than bluetooth. "harder" to access Mysensors ESB than bluetooth for example, plus some security issue that can happen with bluetooth, phones..
- more devices in a network
-
@d00616 What do you foresee regarding the nRF52840? It's presently unsupported.
-
For those who haven't seen it, this Fanstel nRF52832 module is impressively small:
Looks as though it even includes the antenna!
-
Good news. The Fanstel 832X (https://static1.squarespace.com/static/561459a2e4b0b39f5cefa12e/t/59a5a03d579fb36451a25f01/1504026688443/BlueNor_BT832X_datasheets.pdf) module contains the sky66112 (http://www.skyworksinc.com/Product/3152/SKY77927-11z-. which has a PA and an LNA on it. The Rx gain is 11dB, and the TX gain is 22dB. So, this should make for a very good gateway module.
-
@NeverDie they even provide a piece of code to properly activate it
-
@NeverDie said in nRF5 Bluetooth action!:
@d00616 What do you foresee regarding the nRF52840? It's presently unsupported.
In those places where it was obvious, I took the design of the NRF52840 into consideration. I think, when an Arduino port supporting Sketches without SoftDevices is available, then porting is simple. At the moment, I have no plans to expedite an Arduino port.
-
@d00616 said in nRF5 Bluetooth action!:
when an Arduino port supporting Sketches without SoftDevices is availableI
I doubt it will ever happen as all 3 major nrf5 arduino implementations all rely on Softdevice (Primo, Adafruit and Sandeep)
-
@Toyman said in nRF5 Bluetooth action!:
I doubt it will ever happen as all 3 major nrf5 arduino implementations all rely on Softdevice (Primo, Adafruit and Sandeep)
I don't follow what you mean. Aren't we already running the MySensors code without installing the softdevice on the nrf51822 and the nrf52832?
-
@NeverDie Sorry, I meant "BLE implementation without Softdevice"
-
@d00616 said in nRF5 Bluetooth action!:
when an Arduino port supporting Sketches without SoftDevices is available
Is it Sandeep who does that port, or you, or...? I don't have a clear picture as to how many people are working on it, or even who is doing what.
-
@Toyman said in nRF5 Bluetooth action!:
@NeverDie Sorry, I meant "BLE implementation without Softdevice"
I guess the way I read this fog of tea leaves is that nothing is going to happen before final silicon on the nRF52840, and even then there's not much motivating an Arduino port for it. And someday it may happen. i.e. I guess the folks who are doing the heavy lifting are generally happy with the nRF52832 and its capabilities? I probably wouldn't be comfortable relying purely on the nRF52832 if it weren't for the amplified modules that fill the gap. I haven't tried the Fanstel one, but on paper it looks like it's probably good enough for my modest needs.
-
@NeverDie Are you talking about MYS or in general? Because, currently there are two completely different approaches to nrf-arduino. One is based on softdevice (or in broader terms, on SDK) while another works direcly with hardware.
For MYS, our only hope is d00616, if he doesn't do it, chances somebody will apapt 52840 to MYS are negligible.
Frankly, MYS don't need it, but that's just my opinion.
-
@Toyman said in nRF5 Bluetooth action!:
For MYS, our only hope is d00616, if he doesn't do it, chances somebody will apapt 52840 to MYS are negligible.
Please don't be so pessimistic. I expect some very small changes to MySensors to support the NRF52840 platform when arduino-nrf5 is ported to the new NRF5 MCU generation. When arduino-nrf5 supports the NRF52840 platform, I do some tests with the 840DK, I already have.
Looking back to the NRF52832, I think in 6-9 month we can buy NRF52840 modules with production ready chips. I think there is no reason for panic.
-
@Toyman
D00616's explanation increases my optimism considerably because: the people doing the NRF-arduino port care a lot about bluetooth. They'll want to see it through for that reason, because the 840 has much more bluetooth capabilities. Then, once they get that part done, like D00616 says, it will be ripe for porting to MYS. So really, all the interests are aligned. I don't think it will languish. At least, that's the narrative I'm going with.
-
Received this today:
I thought it might have the same PA-LNA as the sky66112 (which also supports antenna diversity) used on the Fanstel, but the lettering suggests otherwise.
-
Here's a better close-up of the chips themselves, which is easier to read:
-
The chip is now owned by Skyworks: http://www.skyworksinc.com/uploads/rfx/RFX2411N_DataSheet.pdf
-
@NeverDie As I may have mentioned before. This was a limited run of prototypes (100 total) designed by RF AXIS and built by Xungtong.. My understanding is that this device is being deemphasized by Skyworks in favor of the SKY661xx family..
Suggested Topics
-
Welcome
Announcements • • hek
