maximum baudrate nrf52 slower than BLE 5.0

RE: maximum baudrate nrf52 slower than BLE 5.0

ovrebekk — Tue, 09 Jan 2018 12:40:51 GMT

The radio surely wouldn't work, since the carrier frequency would be far too high, and the flash memory would not be able to keep up at the higher speeds. Most likely the chip would crash completely because of some internal timing violations.
Usually devices like these are designed to tolerate a certain amount of drift (up to 10% for instance), but once you go beyond that various things on the device are bound to fail. Since we don't test the chip under these conditions we can only guess what would happen.

Try overclocking your desktop CPU to double the frequency, and I am sure you will see similar issues ;)

I don't know if we have tested with WiFi disabled in the settings, but I am pretty sure the ~670kbps limit is enforced by the phone regardless.
I would be happy to be proven wrong in this case :)

Best regards

RE: maximum baudrate nrf52 slower than BLE 5.0

thefool — Mon, 08 Jan 2018 20:39:59 GMT

I see! too bad, I guess... and the clock input is "hardwired" to 16M? and if not: which other peripherals would be affected (or effectively disabled) if it could be changed to 32M?

Did you by any chance test the iPhone with Wifi turned off, and no classic bluetooth devices paired? (see if iOS is smart enough to then give BLE 100% radio time? ;-) (PS: if you do still test that, remember that on iOS 11 Control center Wifi Off != Wifi Radio off! You have to go into the settings to really Disable the Wifi and/or Bluetooth hardware!)

RE: maximum baudrate nrf52 slower than BLE 5.0

ovrebekk — Mon, 08 Jan 2018 14:48:30 GMT

For better or worse we design most of the serial interfaces ourselves, trying to enforce a unified look and feel (including the task/event registers that are used in all Nordic peripherals). This includes the UART, which sets the baudrate exclusively through the BAUDRATE register.

Both the iPhone 8 and X support the high speed mode introduced by Bluetooth 5.
The connection interval when achieving the highest speed is 15ms.
The main limitation in the latest iPhones regarding speed is the event length, which is capped to 50% of the connection interval. This means you are only allowed to send packet for 50% of the available time, even if the connection interval is small. This is probably done to ensure sufficient RF time for other RF protocols (like WiFi or classic Bluetooth), but also means that you will not achieve the highest possible speeds that Bluetooth 5 is capable of.

Best regards

RE: maximum baudrate nrf52 slower than BLE 5.0

thefool — Fri, 05 Jan 2018 16:34:58 GMT

Unless I misunderstand your suggestions they would both require us to make hardware changes to the chip, it's not something we can change in software. In other words I would disagree it's an easy thing to do ;)

In my experience with other micro controllers, 8x oversampling is a very common setting for the uart peripheral, 16x being the default. That setting being a single bit in a register, on the STM32 it is the OVER8 bit in the USARTx_CR1 register. So if you have such a register, then it should be a simple solution, but yeah, if your peripheral hardware doesn't have that, then I agree: not quite so easy :-)

Same with the second suggestion: often it's possible to configure what clock source the peripheral should use, or the other way round: what frequency the peripherals' clock should get. But since often several peripherals share a clock, I'd understand if this suggestion is more difficult...

I get that to make sure the soft device runs 100% smooth it's best not to expose every bit of hardware capability to the user, but the 8x Oversampling bit, if it exists, in my opinion should not cause any harm!

That said: Good point and thanks for the info on the iPhone's max speed: was that measured with the iPhone 8 or X (should both have BLE 5.0) and if yes, with what connection interval? 30ms, 15ms or including the "HID" trick to bring it down to 11.25ms?

Thanks again

RE: maximum baudrate nrf52 slower than BLE 5.0

ovrebekk — Fri, 05 Jan 2018 15:51:52 GMT

I did offer two suggestions for easy and reliable ways of doubling the maximum serial communication speed...
Unless I misunderstand your suggestions they would both require us to make hardware changes to the chip, it's not something we can change in software. In other words I would disagree it's an easy thing to do ;)

well, why offer double bandwidth, if you suggest not to use it? ;-)
Touché ;)
The high speed mode is just as much about reducing current consumption and coexistence issues, as it is about raw data rate.
Phone manufacturers are quick to adopt high speed for this reason, but so far the only phone confirmed to support data rates above 1M is the Samsung Galaxy S8 (and it's variants). The iPhone tops out at around 670 kbps. If you have Nordic devices in both ends, then this is not an issue of course, but if you are planning to talk to a phone then I wouldn't expect to max out the bandwidth very often.

If the CPU was doing nothing else you might have been able to bit bang the communication, but with a high speed BLE link in the background this won't be possible.

Maybe you could feed the UART signal from the STM into the SPI slave interface, and fake the SPI clock and CSN signal locally on the nRF52832, but I really wouldn't recommend it unless you are willing to spend a lot of development time on it ;)

Best regards Torbjørn

RE: maximum baudrate nrf52 slower than BLE 5.0

thefool — Fri, 05 Jan 2018 12:11:01 GMT

Hi, thanks for the reply.

I did offer two suggestions for easy and reliable ways of doubling the maximum serial communication speed...

well, why offer double bandwidth, if you suggest not to use it? ;-)

Yes, we will need to use the maximum possible bandwidth continuously, such as transmitting a live video feed, as in this demo: devzone.nordicsemi.com/.../ only that the camera is attached to the STM. Of course, in less than ideal cases, we won't reach the maximum, but while we can, we'd like to make use of it!

As I wrote in earlier comments, our PCBs are done and we only have UART and I2C connected between the two chips, so no chance to switch to SPI... and even if it were, that's not the question here ;-)

We'll survive with 1M, but would still like to know if we can achieve 2M (or at least 1.4M)

RE: maximum baudrate nrf52 slower than BLE 5.0

ovrebekk — Fri, 05 Jan 2018 10:16:43 GMT

I can't think of any easy and reliable way to achieve serial communication higher than 1MBaud if you only have 2 GPIO's available.

With 3 GPIO's you could do uni-directional SPI up to 4MHz at least (bi-directional if you have 4 GPIO's).

Do you really need to transfer data continuously at a rate higher than 1Mbps?
Keep in mind that 1.4Mbps is the absolute maximum bandwidth, and in practical use the actual bandwidth is likely to be lower than this. By optimizing the application for a lower bandwidth you will have some bandwidth left over for retransmission, making the link more reliable and the data rate more consistent.

Best regards
Torbjørn Øvrebekk

RE: maximum baudrate nrf52 slower than BLE 5.0

thefool — Wed, 03 Jan 2018 23:15:24 GMT

good idea, but the PCBs are already done, the pins won't be usable for SPI on the STM...

RE: maximum baudrate nrf52 slower than BLE 5.0

Turbo J — Wed, 03 Jan 2018 18:06:37 GMT

If your destination is another MCU, try using SPI.