So what's new in this release and why were these changes made? Let's take a quick walk through:
1. User Code Capture Mode
The concept of 'capture mode' has been introduced. For the accelerometer, magnetometer and temperature data sources, the choices of capture mode are AUTO and USER CODE. For general data (previously known as 'pin data'), the choice is restricted to USER CODE.
AUTO Capture Mode
This represents the way in which data was acquired from the accelerometer, magnetometer or temperature sensor previously. Your remote device (e.g. a micro:bit) must have the Bluetooth accelerometer, magnetometer or temperature services in its code, typically achieved with a single block in MakeCode and.... well, that's it. You don't really need to do anything else since those services will take care of sampling data from the associated sensor and transmitting it to Bitty Data Logger automatically.
AUTO capture mode is the mode to use unless you have a good reason not to.
USER Code Capture Mode
 |
| User Code capture mode is available for all data sources |
In the new User Code Capture Mode, your code on the remote device is responsible for acquiring data from wherever it might be, calculating it or deriving it in some other way - the choice is entirely yours. Your code must also transmit it over Bluetooth using the UART service, and in the correct format.
Think of the UART service as allowing you to send and receive messages or byte arrays. It can handle any data, subject to a maximum message length of 20 bytes. A special set of messages have been defined for communication with Bitty Data Logger and you can find details in the new Bitty Software GitHub repository.
Any of the four data types (accelerometer, magnetometer, temperature and 'general data') can be acquired using USER capture mode. General data can only be acquired using USER Code Capture Mode, though.
Motivation and Benefits
So, why was this change made?
USER Code Capture Mode allows you to separate capturing data from transmitting it over Bluetooth. This could mean, for example, that you could write some code for your device which captures data and stores it to a file system as it is being captured. Later, perhaps when a button is pressed or when a Bluetooth connection is established, you'd then read through the stored data and transmit it to Bitty Data Logger. This would be useful in situations where you want to place your device somewhere that it is not practical to have a Bluetooth connection to a smartphone, such as in the great outdoors!
How do you transmit data in user capture mode?
The Bitty Software GitHub repository has lots of code examples. But here's one of them, showing simulated 'general data' being acquired and then transmitted using the UART service.
let connected = 0
bluetooth.onBluetoothConnected(function () {
connected = 1
starttime = input.runningTime()
})
bluetooth.onBluetoothDisconnected(function () {
connected = 0
})
let message_type = 0
let timestamp = 0
let starttime = 0
let value1 = 0
let value2 = 0
let value3 = 0
let value4 = 0
bluetooth.startUartService()
let message = pins.createBuffer(11);
function transmitData() {
timestamp = input.runningTime() - starttime
message.setNumber(NumberFormat.Int8LE, 0, message_type);
message.setNumber(NumberFormat.Int32BE, 1, timestamp);
message.setNumber(NumberFormat.Int16BE, 5, value1);
message.setNumber(NumberFormat.Int16BE, 7, value2);
message.setNumber(NumberFormat.Int16BE, 9, value3);
bluetooth.uartWriteBuffer(message)
}
basic.forever(function () {
if (connected == 1) {
message_type = 1
// random numbers used solely for demonstration purposes. Acquire your data here as required.
value1 = Math.randomRange(0, 1023)
transmitData()
message_type = 2
// random numbers used solely for demonstration purposes. Acquire your data here as required.
value1 = Math.randomRange(0, 1023)
transmitData()
message_type = 3
// random numbers used solely for demonstration purposes. Acquire your data here as required.
value1 = Math.randomRange(0, 1023)
transmitData()
message_type = 4
// random numbers used solely for demonstration purposes. Acquire your data here as required.
value1 = Math.randomRange(0, 1023)
transmitData()
}
basic.pause(1000)
})
It may also be easier to implement the UART on devices which do not automatically have it, like the BBC micro:bit does, than implementing each of the other services.
Note: The Bluetooth Event Service is no longer used for transmitting general data (previously known as 'analog pin data'). You will need to change existing code to use the UART service instead, as shown above.
2. Pin Data is now called General Data
Previous versions supported Analog Pin Data as a data source. The original idea was that you would connect something like a sensor to one of the 3 analog pins numbered 0, 1 or 2 on the edge connector of a micro:bit and that data would be sent as micro:bit 'events' to Bitty Data Logger. It became apparent that people wanted to capture data from other sources, other pins for example. This was technically possible already but meant you might use pin data #0 as a container for data acquired from pin 9, which worked but was potentially confusing. So the is a simple renaming of the concept. 'General Data' items can come from anywhere you like.
3. Up to 4 x General Data Items are now supported
Previously, a maximum of three pin data items could be captured and supported at the same time. The new release allows you to capture and chart up to four general data items. Ideal for use with products like the Sparkfun Weather:bit, perhaps!
 |
| Plotting simulated data transmitted from user code |
4. Accelerometer data is now captured in milli g force
Previously this data was captured in units of g.
5. X-axis scaling options
Previously, your chart would fill and rescale automatically as new values were acquired. Now you choose to have the chart scroll without rescaling. Have a play with this feature to see its effect.
That's all, folks!
