nRF5 action!
-
@NeverDie said in nRF5 Bluetooth action!:
If your goal is to minimize the RX-on time, then you can trigger the RX start and stop by a timer for your minimal window where the frame must be start. Then use the bitcounter top stop the timer in case a packet is received. A shortcut to the end is disabling the RX mode. You can wakeup the CPU with the END event.P.S.: you can reduce the RX/TX time by enabling fast ramp up in MODECNF0 if you haven't to care about nRF51 compatibility.
-
@NeverDie said in nRF5 Bluetooth action!:
If your goal is to minimize the RX-on time, then you can trigger the RX start and stop by a timer for your minimal window where the frame must be start. Then use the bitcounter top stop the timer in case a packet is received. A shortcut to the end is disabling the RX mode. You can wakeup the CPU with the END event.P.S.: you can reduce the RX/TX time by enabling fast ramp up in MODECNF0 if you haven't to care about nRF51 compatibility.
@d00616 said in nRF5 Bluetooth action!:
@NeverDie said in nRF5 Bluetooth action!:
If your goal is to minimize the RX-on time, then you can trigger the RX start and stop by a timer for your minimal window where the frame must be start. Then use the bitcounter top stop the timer in case a packet is received. A shortcut to the end is disabling the RX mode. You can wakeup the CPU with the END event.P.S.: you can reduce the RX/TX time by enabling fast ramp up in MODECNF0 if you haven't to care about nRF51 compatibility.
Thanks! It finally dawned on me that having the PPI use the RTC's CC registers would be a far better way to schedule turning on and off the radio's RX than using the stopgap analog delay that I had devised (above). Your interrupt handler example helped me see what had been staring me in the face the entire time, but without my recognizing it as the answer to the problem. Funny how that can sometimes happen, where the whole gestalt can just suddenly change. So, thanks again for sharing your example code. This will be a much less awkward solution! :)
-
Where exactly do I look to find all the pin mappings that are assumed for the "Generic nRF52" board? For example, what are the pin numbers that are assumed for RXI, TXO, MISO, MOSI, etc.?
-
I just now posted a source code example and hardware demo for my recently completed breakout board which uses "MyNRF52Board nRF52832" board as the reference when compiling within the Arduino IDE:
https://www.openhardware.io/view/471#tabs-sourceI think from this point forward I'm going to use "MyNRF52Board nRF52832" for any custom boards I develop. Thanks to @d00616, it is a very convenient framework for organizing and enabling the preferred pin mappings. :)
-
Looks as though the nRF52832 sparkfun board has more of a conventional trace antenna:
though isn't it somewhat odd that it appears to also be directly connected to the ground plane(?), or at least a copper pour. Is that normal? This was one of the images produced by sending their .BRD file to oshpark, so that I could get a look at the antenna.@NeverDie That is a meandered Inverted F Antenna (IFA). It will give you better performance then a standard meandering antenna and a much smaller size then a standard 1/4wave trace antenna. Not as easy to tune however. You can read about the one that TI designed for their 2.4Ghz dongle. http://www.ti.com/lit/an/swra117d/swra117d.pdf
Of course this is not Device dependent as you need to feed it with a 50 ohm feed point. A Pi network before between the Chip's ANT output and the Antenna is desired from a tuning standpoint.Note that on the nRF52 designs, the two components (Cap and Inductor) connected to the ANT pin are used for harmonic filtering AND impedance matching and has nothing to do with the antenna tuning other to present a 50ohm feed point.
-
@NeverDie That is a meandered Inverted F Antenna (IFA). It will give you better performance then a standard meandering antenna and a much smaller size then a standard 1/4wave trace antenna. Not as easy to tune however. You can read about the one that TI designed for their 2.4Ghz dongle. http://www.ti.com/lit/an/swra117d/swra117d.pdf
Of course this is not Device dependent as you need to feed it with a 50 ohm feed point. A Pi network before between the Chip's ANT output and the Antenna is desired from a tuning standpoint.Note that on the nRF52 designs, the two components (Cap and Inductor) connected to the ANT pin are used for harmonic filtering AND impedance matching and has nothing to do with the antenna tuning other to present a 50ohm feed point.
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie That is a meandered Inverted F Antenna (IFA). It will give you better performance then a standard meandering antenna and a much smaller size then a standard 1/4wave trace antenna. Not as easy to tune however. You can read about the one that TI designed for their 2.4Ghz dongle. http://www.ti.com/lit/an/swra117d/swra117d.pdf
Of course this is not Device dependent as you need to feed it with a 50 ohm feed point. A Pi network before between the Chip's ANT output and the Antenna is desired from a tuning standpoint.Note that on the nRF52 designs, the two components (Cap and Inductor) connected to the ANT pin are used for harmonic filtering AND impedance matching and has nothing to do with the antenna tuning other to present a 50ohm feed point.
It looks the same as the antenna on the Ebyte E73-2G4M04S nRF52832 module. Is there any difference? i.e. are you just supplying background information, or are you making a suggestion for improvement?
-
It's not clear whether the DK can/should be used for this part of it, as it's unclear (at least to me) whether it will end up altering the target chip or the DK. I'm just not sure. So, to do at least this ambiguous part of it, I'll first check whether or not the nRFgo studio software will work with one of the other programmers I've collected (not the DK). That may take a while...
@NeverDie nRFgo Studio uses the Segger J-link firmware. When using the Softdevice make sure that your application does not start below the top of the Softdevice or you will get a error on most programmers that there is something located in that protected space. If it does not see this as a protected area then you will corrupt the Softdevice.
Most programmers only need the two SWD lines, ground and a voltage reference from your target board back to the programmer. This is to tell the programmer you have a target board connected and what voltage it is running on. Note that the nRF52-DK does NOT have voltage translators on the programming lines (P19 and P20) so you must be powering your target boards with 3vdc to 3.3vdc. (I have tested down to 2.8vdc but it is not guaranteed to work consistently.) Not sure about ST or other programmers.
-
Here's a photo with the lid pried off:
Maybe we can reconstruct what's going on just from looking at the components and the trace lines? At least for now, I'm not so concerned with the RF part.@NeverDie someone did not read the datasheet. The harmonic filter / impedance matching network on the output of Pin 30 (ANT) is connected incorrectly. There needs to be abolded text Cap from ANT out to Pin 31 ONLY. (Not connected to any other ground pour as it seems they did here. Seems to be a few "extra components between there and the Antenna matching network too.
From the nRF52832 datasheet.
bolded text53.8 PCB layout example
The PCB layout shown below is a reference layout for the QFN package with internal LDO setup.
Important: Pay attention to how the capacitor C3 is grounded. It is not directly connected to the
ground plane, but grounded via VSS pin 31. This is done to create additional filtering of harmonic
components.[link text](link url) -
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie That is a meandered Inverted F Antenna (IFA). It will give you better performance then a standard meandering antenna and a much smaller size then a standard 1/4wave trace antenna. Not as easy to tune however. You can read about the one that TI designed for their 2.4Ghz dongle. http://www.ti.com/lit/an/swra117d/swra117d.pdf
Of course this is not Device dependent as you need to feed it with a 50 ohm feed point. A Pi network before between the Chip's ANT output and the Antenna is desired from a tuning standpoint.Note that on the nRF52 designs, the two components (Cap and Inductor) connected to the ANT pin are used for harmonic filtering AND impedance matching and has nothing to do with the antenna tuning other to present a 50ohm feed point.
It looks the same as the antenna on the Ebyte E73-2G4M04S nRF52832 module. Is there any difference? i.e. are you just supplying background information, or are you making a suggestion for improvement?
@NeverDie Pretty much a reference only. In a previous post you inquired about the grounding on the meandering antenna. I posted the TI application note as a frame of reference only. However if you do create your own module you should be aware that the two matching components coming off the ANT pin are NOT antenna matching components but are three for output impedance matching and also acts as a low pass filter. Pi network is still required for tuning of the antenna. (may not use all three components after tuning)
-
@NeverDie nRFgo Studio uses the Segger J-link firmware. When using the Softdevice make sure that your application does not start below the top of the Softdevice or you will get a error on most programmers that there is something located in that protected space. If it does not see this as a protected area then you will corrupt the Softdevice.
Most programmers only need the two SWD lines, ground and a voltage reference from your target board back to the programmer. This is to tell the programmer you have a target board connected and what voltage it is running on. Note that the nRF52-DK does NOT have voltage translators on the programming lines (P19 and P20) so you must be powering your target boards with 3vdc to 3.3vdc. (I have tested down to 2.8vdc but it is not guaranteed to work consistently.) Not sure about ST or other programmers.
@Jokgi said in nRF5 Bluetooth action!:
you must be powering your target boards with 3vdc to 3.3vdc. (I have tested down to 2.8vdc but it is not guaranteed to work consistently.) Not sure about ST or other programmers.
Thanks for reminding me of this. It turns out to be true for the J-Link programmers which are for sale on Aliexpress.com as well.
-
@Jokgi said in nRF5 Bluetooth action!:
you must be powering your target boards with 3vdc to 3.3vdc. (I have tested down to 2.8vdc but it is not guaranteed to work consistently.) Not sure about ST or other programmers.
Thanks for reminding me of this. It turns out to be true for the J-Link programmers which are for sale on Aliexpress.com as well.
@NeverDie I am not sure about all the boards for sell on that site. but I would have to say that any J-link programmer that is packaged as such for $12-$40 dollars is probably counterfeit. Updating these items with newer J-link firmware would more then likely disable them. (On purpose) You may wish to contact Segger in Boston prior to spending money on these potential clones. I would be interested to hear what experiences other people have had with the products from that site.
The genuine J-link and j-link plus programmers are over $400.00 as you can see on the Digi-Key website. Per the Segger license agreements, the only J-link 0B devices that are able to be sold are to be bundled with a Evaluation / Development kit such as the nRF52-DK, ST, Rigato, and other semiconductor / module manufacture's dev kits.
-
@NeverDie I am not sure about all the boards for sell on that site. but I would have to say that any J-link programmer that is packaged as such for $12-$40 dollars is probably counterfeit. Updating these items with newer J-link firmware would more then likely disable them. (On purpose) You may wish to contact Segger in Boston prior to spending money on these potential clones. I would be interested to hear what experiences other people have had with the products from that site.
The genuine J-link and j-link plus programmers are over $400.00 as you can see on the Digi-Key website. Per the Segger license agreements, the only J-link 0B devices that are able to be sold are to be bundled with a Evaluation / Development kit such as the nRF52-DK, ST, Rigato, and other semiconductor / module manufacture's dev kits.
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie I am not sure about all the boards for sell on that site. but I would have to say that any J-link programmer that is packaged as such for $12-$40 dollars is probably counterfeit. Updating these items with newer J-link firmware would more then likely disable them. (On purpose) You may wish to contact Segger in Boston prior to spending money on these potential clones. I would be interested to hear what experiences other people have had with the products from that site.
The genuine J-link and j-link plus programmers are over $400.00 as you can see on the Digi-Key website. Per the Segger license agreements, the only J-link 0B devices that are able to be sold are to be bundled with a Evaluation / Development kit such as the nRF52-DK, ST, Rigato, and other semiconductor / module manufacture's dev kits.
When would I need to upgrade the firmware? At least for now it seems to work just fine.
-
@NeverDie I am not sure about all the boards for sell on that site. but I would have to say that any J-link programmer that is packaged as such for $12-$40 dollars is probably counterfeit. Updating these items with newer J-link firmware would more then likely disable them. (On purpose) You may wish to contact Segger in Boston prior to spending money on these potential clones. I would be interested to hear what experiences other people have had with the products from that site.
The genuine J-link and j-link plus programmers are over $400.00 as you can see on the Digi-Key website. Per the Segger license agreements, the only J-link 0B devices that are able to be sold are to be bundled with a Evaluation / Development kit such as the nRF52-DK, ST, Rigato, and other semiconductor / module manufacture's dev kits.
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie I am not sure about all the boards for sell on that site. but I would have to say that any J-link programmer that is packaged as such for $12-$40 dollars is probably counterfeit. Updating these items with newer J-link firmware would more then likely disable them. (On purpose)
Yes they are of course counterfeit, and using old firmware. You have a message when you use them with Segger software asking you to upgrade to newer firmware and if you accept your programmer is disabled (web is full of solutions to reflash a firmware).
But if you don't upgrade the firmware it works fine as a SWD programmer, at least for basic use (programming). I have not tried any debugging. -
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie I am not sure about all the boards for sell on that site. but I would have to say that any J-link programmer that is packaged as such for $12-$40 dollars is probably counterfeit. Updating these items with newer J-link firmware would more then likely disable them. (On purpose)
Yes they are of course counterfeit, and using old firmware. You have a message when you use them with Segger software asking you to upgrade to newer firmware and if you accept your programmer is disabled (web is full of solutions to reflash a firmware).
But if you don't upgrade the firmware it works fine as a SWD programmer, at least for basic use (programming). I have not tried any debugging. -
Are we limited to using RTC0? I've tried switching to RTC1 and RTC2, and I get the sense there are conflicts with both of them and the MySensors code if they're used.
@NeverDie said in nRF5 Bluetooth action!:
Are we limited to using RTC0? I've tried switching to RTC1 and RTC2, and I get the sense there are conflicts with both of them and the MySensors code if they're used.
RTC1 is blocked by arduino (nRF5/delay.c) and RTC0 (nRF51) and RTC2 (nRF52) is used in MySensors (hal/architecture/MyHwNRF5.cpp)
-
Success. I now have a "listen mode" for the nRF52832 radio that's completely controlled by the PPI while the MCU sleeps. Presently, it wakes up the radio every 100ms and listens for 1ms. This means no wasted power from oversight by the MCU. Using just the PPI, I can control to within about 30us over how long to make the cycle period and/or the listening duration.
The scope shots show the current drawn. Scale: 1mv=1ma. As you can see, the DCDC regulator is engaged.
Next step will be to have packet receipt wake up the MCU via an ISR, so that the packet can be processed. After that, I'll see how narrow I can make the receive window and still receive packets reliably. I think under 100us will be possible. Maybe even less than 60us if the bitrate is 2mbps. :)
-
Success. I now have a "listen mode" for the nRF52832 radio that's completely controlled by the PPI while the MCU sleeps. Presently, it wakes up the radio every 100ms and listens for 1ms. This means no wasted power from oversight by the MCU. Using just the PPI, I can control to within about 30us over how long to make the cycle period and/or the listening duration.
The scope shots show the current drawn. Scale: 1mv=1ma. As you can see, the DCDC regulator is engaged.
Next step will be to have packet receipt wake up the MCU via an ISR, so that the packet can be processed. After that, I'll see how narrow I can make the receive window and still receive packets reliably. I think under 100us will be possible. Maybe even less than 60us if the bitrate is 2mbps. :)
@NeverDie Great Job!!!! Suggestion... If you are going to use the BTLE Softdevice you will have a smaller receive window if you use the external 32khz crystal option rather then the internal 32khz RC one. (+/- 20ppm with the crystal vs +/- 250 or 500ppm with the RC.
-
At the extreme, one of the questions that will need answering is: what's the minimum number of bytes in a transmitted frame that you really do need before the receiver starts receiving garbage packets? For instance, a 10 byte frame, which should be more than adequate, would take 40us of airtime to either transmit or receive at 2mbps bitrate. One could get to a lower number by maybe sending a null packet as a wake-up packet, in which case maybe you also don't need CRC. So, that leaves you with some preamble, a network ID, and maybe a destination ID--or about 5 bytes. So, that would be around 20us of airtime. One could shrink that further by reducing the number of network ID bytes, but too much of that and possibly one starts to receive garbage packets.
The RFM69 doesn't try to decode packets whose RSSI is below a specific programmable threshhold. I don't believe the nRF52 radio uses RSSI as a filter in that way though. It seems that the nRF52832 radio tries to decode whatever it's receiving, regardless of the RSSI. Or, at least, that's how I remember it. Anyone else played around with it?
