Our coffee maker is one of the most prized assets in the office, so naturally it's important to keep it on a regular maintenance schedule. One of the most important tasks is to make sure to empty the trashbin of coffee grounds at a regular interval, to make sure it does not overflow.
To solve this we added a digital scale underneath it, and connected that to one of our WSTKs. Torkil did all the difficult stuff here, but short summary: The scale sends out a pulse train where the duty cycle corresponds to the weight. We can then measure the high-period and knowing what it's like when empty and full we can then calculate a fill-level. Hereare some pictures of the process:
Opening the scale:
Figuring out what is where:
And we get a ratio between weight/fill-level and duty-cycle:
Final mounting of the scale/transmitter:
The fill level is expressed in one byte and transmitted wirelessly. I just took the bidirectional example in Simplicity Studio and use the first byte of the data struct for actually transmitting data. The next 15 bytes I just left there. The weight is measured every 200 ms, and the weight is transmitted every second. As the readings from the scale can be quite unstable, every reading is actually measuring 8 pulses, then I have a static variable which is updated using a super-simple filter:
value = newValue*0.1 + value*0.9;
The Thunderboard Sense then picks up this byte and display the byte as a color between green (0x0) and red (0xFF). Actually 0x0 holds a special meaning, that the WSTK cannot get a good reading so the fill-level actually starts at 0x1.
There are also a couple of other functions for testing.
1) Pressing a button on the WSTK sends a random weight. Useful for testing when it's not connected to the scale
2) Pressing a button on the Thunderboard Sense sends a packet to the WSTK and changes the color to purple when it receives an ACK. Useful for testing connectivity.
3) If more than 10 seconds passed without receivng a packet, the Thunderboard Sensestarts blinking yellow and will send a packet every second to try to re-initiate the connection.
4) If only 0x0's are received from the WSTK, Thunderboard Sense will blink blue to inform the user that something is probably wrong.
The files available on https://github.com/SiliconLabsLabs/ConnectedCoffee contains one example for the WSTK and one example for the Thunderboard Sense. The Thunderboard Sense example is the same bidirectional example, but updated to work with TB-S. As there is currently no support for Thunderboard Sense in the RAIL SDK, an additional board-folder is added, BRD4160A. The Thunderboard Sense example also contains some files copied from the BLE Thunderboard Sense example, such as the RGBLED driver.
In general these examples shows a simple use-case of the lower level radio functions coupled with RGBLED-drivers for the Thunderboard Sense and using the rtcdriver for timekeeping.
In the drawer under the coffee machine:
Thunderboard Sense on top of the machine:
The next steps are obviously to get it cloud connected. I'm hoping to use Thread for this. Just have to set up an internet connected Thread network here at the office. Why isn't there one here already?
Code is available here: https://github.com/SiliconLabsLabs/ConnectedCoffee
@Alf - love your connected coffee project; clever use of some cool dev boards.
I've just received my Thunderboard Sense, and am looking for some direction on a project I'm thinking up. Essentially I'd like to have a standalone sensor in my house. This sensor then transmits the sensor data (mainly IAQ) direct to the cloud.
Obviously the Thunderboard Sense is BLE only, so I need a way to get the information uploaded to the cloud, perhaps once per minute, continuously.
Perhaps there is a way through the USB port to receive the values, or through the I2C (although this looks slightly complicated given the waking up and power saving etc.)?
Any ideas here? Where should I start looking? (perhaps a gateway between BLE and Wifi), or is there some other trick?
@ØyvindB - thanks for the suggestions here however I'm not a Raspberry Pi man, and so am trying to figure it out with some other boards (Particle Photon with Bluz board), so will look to find some examples with that.
If I get stuck then I'll look to the community for help, but so far so good.
Just saw your post, sorry about the long delay. Obviously something funky with the forum notifications.
The Thunderboard Sense is not BLE only, it can run any protocol from Silicon Labs, from the simple RAIL-examples in this post to the Thread protocol in other posts. However the easiest is to use the pre-programmed BLE example as you've seen. It is a peripheral device meaning that it will only be the transmitter of data, not the central, so you have to have a central (phone, RPi) to collect the data.
If you want to do something else, the Thunderboard Sense comes with a serial port over the USB (a virtual COM-port (VCP)), so it's not too hard to write a serial app on the Thunderboard that just prints something over the VCP to the computer/Raspberry. This Thunderboard can then be set up to receive data from other Thunderboards just like I've done with the fill-level in the example above.
@Alf - I understand there are different protocols, however not being an expert in any of them I thought I might try my hand at the Central BLE version (Bluz gateway allows this).
I haven't got the Gateway yet, so unable to try anything until the postman knocks on the front door!
Will let you know how I get along.