nRF5 action!
-
How are people here preferring to connect to their nRF5x node for programming/debugging? I had been using a 10-pin IDE boxed connector on the PCB's I was making, but I just recently tried a micro-USB OTG connector (just as a 5-pin connector, not for anything truly USB protocol related), and I find that I like it a lot. For one thing, it's a lot more compact:
It does require making an adapter, but once you've made it (once and done), it's easy.
Any thoughts on this? I'm tentatively leaning toward switching over to it for everything.
@NeverDie I think it's ok only if you keep those only for yourself, and/or make an enclosure hiding this plug.
Because if you give to someone like a friend and an USB plug is visible one day or another they'll plug it and fry the board with 5V :) -
@NeverDie I think it's ok only if you keep those only for yourself, and/or make an enclosure hiding this plug.
Because if you give to someone like a friend and an USB plug is visible one day or another they'll plug it and fry the board with 5V :)Good point. To avoid that as a potential problem then, can anyone suggest a better connector to use?
-
Good point. To avoid that as a potential problem then, can anyone suggest a better connector to use?
I suppose if/when OTA updates are developed for the nRF5x's, then the issue would go away. Then you'd only need the connector when first setting it up, and then later work could be uploaded OTA. After the initial setup, one could simply sabotage the USB connector (fill it with epoxy maybe, or perhaps just cut the traces) to prevent the friend from plugging the node into an actual USB charger or the like.
-
Good point. To avoid that as a potential problem then, can anyone suggest a better connector to use?
-
@NeverDie check out a product called "TAG-CONNECT". It is perfect for programming. It is used on the Nordic Semiconductor Beacon Reference Design.
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie check out a product called "TAG-CONNECT". It is perfect for programming. It is used on the Nordic Semiconductor Beacon Reference Design.
Thank you. Here is an programmer with this connector: http://aconno.de/acnprog/
I don't know if this is compatible to the Beacon Reference Design, but its compatible with the nRF52 boards provided by aconno. -
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie check out a product called "TAG-CONNECT". It is perfect for programming. It is used on the Nordic Semiconductor Beacon Reference Design.
Thank you. Here is an programmer with this connector: http://aconno.de/acnprog/
I don't know if this is compatible to the Beacon Reference Design, but its compatible with the nRF52 boards provided by aconno.@d00616 not familiar with the USB interface / tag connect. The ones I have used have the connector type that plugs onto the nRF5x-DK, uLinks, jlink lite, etc. a ten pin Micro Cortex connector to six or ten pin "pogo pin" tag-connect connector. There is also a clip that allows the connector to stay attached for debugging purposes.
-
A bit off-topic perhaps, but does anyone here happen to know what kind of switch Enocean uses to transduce a button press into the electrical energy needed to send a packet? I'm guessing it's some kind of piezo switch. Can just that transducer part be purchased by itself? I'm wondering whether the same trick can be done using an nRF5...
-
I would stick with cortex 10-pin connector. Mostly because it's (a) standard (b) a cable can be made without soldering by using IDC connectors and a ribbon cable.
The only downside is height.
Using USB connector for sometging that's not USB is generally a bad idea as it's not foolproof -
Is signing soft supported or not yet ?
The personalizer sketch do not have hash define for the NRF52.
-
Is signing soft supported or not yet ?
The personalizer sketch do not have hash define for the NRF52.
@ahmedadelhosni pull requests are always welcome.
-
Is signing soft supported or not yet ?
The personalizer sketch do not have hash define for the NRF52.
@ahmedadelhosni said in nRF5 Bluetooth action!:
Is signing soft supported or not yet ?
The personalizer sketch do not have hash define for the NRF52.The security personalizer is working with the NRF5X. Random numbers for the Soft Signing are generated with the internal AES hardware, seeded with the hardware number generator. This allows a fast and secure nonce generation.
At the Moment the NRF5 with Soft Signing is not at the same level like the ATSHA204, because the read back protection is not enabled. If you want to do this, you have to add some code.
-
What else should I turn-off to save power during sleep?
Presently, I turn-off these things: the radio, NFC, the high frequency clock, and uarte, Meanwhile, the low frequency clock is working.
Presently getting a sleep current drain of apprxoimately 2.8 microamps.
-
What else should I turn-off to save power during sleep?
Presently, I turn-off these things: the radio, NFC, the high frequency clock, and uarte, Meanwhile, the low frequency clock is working.
Presently getting a sleep current drain of apprxoimately 2.8 microamps.
@NeverDie said in nRF5 Bluetooth action!:
What else should I turn-off to save power during sleep?
Presently, I turn-off these things: the radio, NFC, the high frequency clock, and uarte, Meanwhile, the low frequency clock is working.
Presently getting a sleep current drain of apprxoimately 2.8 microamps.
Which chip are you talking about ?
-
nRF52832. I'm guessing the same will apply to the nRF51822, except for the NFC (which the nRF51822 doesn't have).
-
I should probably add that the 2.8ua is with the RTC and LPCOMP running. So, maybe it's already as low as it can go, I don't know. Just wondering if there are any other obvious suspects I should try turning off. I'll try i2C and SPI to see if it makes a difference... Not sure, but maybe SPI gets initialized through the header file without my even being aware of it.
-
Well, it could be within the bounds of measurement error, but it appears that dropping I2c and SPI has reduced the drain to 2.6ua.
@NeverDie said in nRF5 Bluetooth action!:
Well, it could be within the bounds of measurement error, but it appears that dropping I2c and SPI has reduced the drain to 2.6ua.
Is I2C or SPI used somewhere in your code?
-
@NeverDie said in nRF5 Bluetooth action!:
Well, it could be within the bounds of measurement error, but it appears that dropping I2c and SPI has reduced the drain to 2.6ua.
Is I2C or SPI used somewhere in your code?
@d00616 said in nRF5 Bluetooth action!:
@NeverDie said in nRF5 Bluetooth action!:
Well, it could be within the bounds of measurement error, but it appears that dropping I2c and SPI has reduced the drain to 2.6ua.
Is I2C or SPI used somewhere in your code?
Not in the current test code that I'm running.
-
@d00616 said in nRF5 Bluetooth action!:
@NeverDie said in nRF5 Bluetooth action!:
Well, it could be within the bounds of measurement error, but it appears that dropping I2c and SPI has reduced the drain to 2.6ua.
Is I2C or SPI used somewhere in your code?
Not in the current test code that I'm running.
@NeverDie said in nRF5 Bluetooth action!:
Not in the current test code that I'm running.
Interesting. The SPI is rated with <1µA idle current. TWI has no idle current in the datasheet.
