Using FLCLK to drive clock on pressure sensor


#1

Im planning on using my Bluz with a MS5541C pressure sensor that requires a 32.768khz clock, is it possible to use the clock in the nRF51822? i see there is XL1 and XL2 for an external oscillator… but is there a way to bring the internal oscillator out? through software even?

it would be nice to be able to turn the clock off too to save power… the whole 0.5uA or whatever the pressure sensor draws on the clock pin

Here is the datasheet for the pressure sensor (


#2

@Hootie81, that a look here:

https://devzone.nordicsemi.com/question/1111/lfclk-32khz-on-a-gpio-pin-for-precision-measurement/

:smile:


#3

@peekay123 beat me to it! But yes, PPI should work well for this type of application. Functionality like this may not be exposed through the base API when we first ship, but the entirety of the Nordic SDK is available to you so examples found in the Nordic Dev Zone or anywhere else will work perfectly fine on bluz.


#4

Wow… well above my pay grade!

will using this effect other things like micros()? there is a note in the docs, does that mean the clock will already be running?

Note:
To preserve low power consumption, this uses the 32,768kHz LFCLK to keep
track of microseconds, meaning resolution is reduced. Each tick of the
clock is approximately 30 microseconds, so greater resolution than that
cannot be obtained.

also can this low level code be compiled in the user app?
also kinda unrelated but kinda the same… does the particle web IDE compile for Bluz now? so we just select the device and it builds for that target?


#5

This shouldn’t affect micros. The idea behind PPI is that the peripherals can talk without involving the processor. While we use RTC1 for some timing functions, these can run in parallel as our functions don’t use PPI.

What this could affect is the number of PWM outputs available. PWM in Nordic also uses PPI to drive the pins so the processor isn’t involved. But there are a limited number of channels, so it’s a finite resource. Something like this will reduce the number of available PWM pins by one.

And yes, this will compile in the user app and yes, the Web IDE currently can compile for bluz.


#6

Sweet now im more excited than ever to receive my Bluz…

One last question for the same sensor. is it possible to configure more than one SPI interface on the Bluz - ie one system one for the SPI flash and a separate one for the user? the sensor doesn’t have a CS line… and i also want to use an LSM9DS1 IMU in SPI mode too. I see in the hardware section of the docs that it can be reconfigured to any of the pins, but im not sure if its possible in this use case.

And while im hammering you with questions, how much of the SPI flash is available for the user? im wanting to log the data and send it once a day when connected to the gateway.


#7

There are two SPI peripherals in bluz. We dedicate one for the SPI Flash and the other is fully available to the user. So you can use the one SPI interface without worrying about interfering with the on-board flash.

At this point, there won’t be much of the external flash available for the user. However, you can use the internal flash to store data as well. The current plan is to allow 32KB for the user app+data. On the one hand, we hope we can offer more than that but on the other, we hope it doesn’t extend beyond the 32KB as we implement the final set of feature. For now, 32 KB is a good estimate.

How much flash do you need?


#8

I dont know… i have an idea of what i want to log, but haven’t calculated anything yet. Im thinking Pressure and temp every 15min, and 60 seconds of accel/Gyro/compass+pressure every hour at maybe 2samples/sec.

and then connect to gateway and send it all once per day or every second day.

Need to work out battery too… im thinking 2x AAA to keep cost down. pressure i want to monitor every 30sec, and only advertise when a certain criteria met…


#9

@Hootie81, you could use software SPI for the pressure sensor since sampling speed is not an issue. You could also use I2C FRAM for storing your data (an SPI version is also available). Based on your sampling regime and assuming you store everything in DOUBLE format (8 bytes each), you would need about 24KB of data which fits nicely in a 32K FRAM. These are also very low power with 200uA operating and 27uA standby current. :smile:


#10

Honestly, you may be able to get away with publishing more and storing less. Bluz is very low powered even when connected, you should get many months of battery life from AAA batteries while staying connected to the cloud and publishing data. It all depends, of course, on your use case and settings, but you really shouldn’t need to store and then connect once a day to save power. In WiFi this makes sense as the radio draws a high amount of current, but that isn’t the case with BLE.


#11

@Hootie81 is this related the transducer I am looking for? If not I like it for that use…3D print a housing and done!


#12

@eric it might be a little hard to connect to a gateway 80m deep in the sea! plan is to pull the device once per day, or every second day depending on weather, when the device senses its near the top it starts advertising, connects to the gateway/phone and sends data to a server. i will probably need some error checking because there is a chance it could bread the surface then go under again. also there is possibly a time constraint, the device might only be above the water for 30-60seconds. also it needs to be all automagic connecting, i dont want to have my phone out pushing buttons when out at sea with water spraying everywhere.

@LukeUSMC use case is a little different, Im thinking of using the MS5541C, but its stupidly expensive and i cant find any other pressure transducers that have similar mounting and pressure rating.

oh and as for batteries, i would like 3+ years battery life, that way i can have fully sealed units and not worry about water ingress


#13

ah, well yes, i can see how that would be difficult :smile:

so is the back-end connection the phone? how far out at sea? will it be a reliable internet connection?

another consideration is the data throughput. BLE is slow. ultimately, the data limit is probably more constrained by the Particle publish limit, but just something to keep in mind. connections to the cloud can sometimes take 20-30 seconds, but are much faster when using a smartphone than a gateway. still, if there is a hard time limit that you have access to these things, it is something to look at.

you should be able to get very long battery life. in your case, yes, you can turn off the radio for the majority of the life of the device, which is a big savings.


#14

Good idea @peekay123 i dont think you can use I2C and SPI at the same time on Bluz (from the docs), in fact i have one of @kennethlimcp’s SD/FRAM boards in my hand for prototyping :slight_smile: and its SPI…win!

@eric Normally there is still phone coverage, but there will definitely be cases where there is not. but i guess data could be stored on the phone until a connection exists.

i was planning on using the Particle system for managing the devices + OTA updates etc but developing my own method of data collection + analysis (although if particle did offer something like this it would be totally awesome!)
there will also be a phone app that collects other environmental and position data.

First steps first - i need a working prototype

Also i plan on using just the nrf51822 module flashed with your bluz software, what pins should i break out in case i mess up firmware? when will the pre-flashed modules be available?


#15

Makes sense.

As for the modules, I can probably get you some now if you want to flash them yourself. It is pretty easy, you only need to break out two lines for SWD and you can use an STLink or other JTAG programmer to flash whatever you want onto the module. Those are the lines to break out as well in case you have issues.

The bootloader will also talk over UART, if you need to, but I would recommend just leaving the SWD lines as an option. For $20 you can get an STLink v2 and then you are covered against any situation. If space isn’t an issue, you can leave a small, 0.05" 10-pin header as we do on the gateway shield.


#16

Ill get a test board drawn up over the next few weeks, im away from home at the moment so cant do much for 3 weeks anyways.

the SWD option, do i need an earth too? im just thinking if i seal up the device to make it water tight i could have a couple of metal pads to reflash if needed.

Ill probably do a reed switch to wake the device from sleep. and a few reed switches to remove any potential between pins and corrosion whilst in the sea water. Could do a special base with a magnet in it, for programming and possibly recharging of test units.


#17

My old dive computer used a cable like this…really annoying to have something so specialized and the spring broke so I had to rig it up everytime I wanted to transfer data from the computer. But if you can find what the composition of the contact pads are you could use that for your base. Sounds like dive computers might be a great analog for what you are working on.


#18

@LukeUSMC yeah its always a challenge to transfer from sealed devices. its really just a backup though, ideally i will just have a singe reed switch to wake the device and turn ble on, so it can OTA update. the pins idea was a just in case & more for prototype/testing. final units may not have anything, i could base it on accel/mag picking up movement

Ive had a few dive computers over the years with similar cables, the worst was the infrared one for the mares nemo computer - if you misaligned the IR by 2mm it wouldn’t connect


#19

My board design is complete and sent away for fab. It looks really cool and i managed to keep it within a 30mm diameter circle! it has a CR2450 battery on the back

So the 3 large pads in the top right are these target things so i can fully pot the device and still have access to the SWDIO, SWCLK and GND. (thats all i need right?)

its amazing how hard it is to route things in such a small space. i really hope i chose the right pins to connect things to, i just chose the closest ones for the I2C IMU (P0.06 and P0.07) and for the software SPI I’m using P0.02 to P0.05. I left the SPI for the flash on the same pins to make things the same as Bluz.

Its a shame the 3mm x 2mm version of the flash is so hard to find, not even digikey have it in stock. that would help shrink things down too.


Bluz ADC and FSRs?
#20

Looks awesome!

Technically, you should have the 3V line exposed as well to program over SWD. However, it may actually work with the STLink without this, I haven’t tried. With a Segger JLink programmer, this line is used purely to sense voltage. But with the STLink, we seemed to have learned it actually provides power as well. So it is possible that you wouldn’t need the 3V line hooked up, I have never tried this.

If you do, luckily there is a giant 3V pad on the back of your board in the battery clip. So whatever programming rig you have could just tap into that if you need to. Would probably be better anyway if space constraints are a concern.

The nrf51 is very forgiving when it comes to pin mapping, pretty much any pin can be used for any function. The big exception to that are analog pins and SWD, but for SPI/I2C you can use pretty much anything you want.

Are you using both at the same time? What are you using them for respectively? With bluz, I2C and SPI can’t be used at the same time as they share resources underneath. You can switch between them, just can’t open both at the same time.

What sensors are on there? An IMU and what?