calliope-mini / microbit-dal Goto Github PK

Hi,
I'm actually testing some bluetooth services and am experiencing several problems. Some of them are already known.

1. Accelerometer data over BLE does not work
   As reported by @smartyw in #7.

2. Callibration of compass not possible if Bluetooth-IO-Pin-Dienst is working.
   I'm not sure if this is related to #4. However, calibration fails with the last dot of the cirlce and shows several times 'sad face'-020. When not using the Bluetooth-IO-Pin-Dienst compass calibration works nicely.

3. The 'compass calibration' service is missing
   This bluetooth characteristic (E95DB358-251D-470A-A062-FA1922DFA9A8) is available on the micro:bit. It can be used to invoke the compass calibration.
   The 'problem' is that some libraries, eg. python-bluezero (https://github.com/ukBaz/python-bluezero), are expecting this service, so you cannot use this libraries without manually patching them.

I'm using a 'new' Calliope (name on left side below A button, '1.3' on the back-side right to the USB port).

Regarding topic 1 I think that @smartyw has already gave you some hints where the problem may be located.

Do you think that you will address this issues in the near future? E.g. #7 is from June 2018.

Some response here on GitHub would be nice!

Set-up to reproduce
Generate a program with the makecode editor using bluetooth blocks:

Use "no pairing required" in the project setup:

You need to remove the Bluetooth-IO-Pin-Dienst to make the other things working.

Now, use some software (e.g. Linux blueZ over bluetoothctl or an app like Nordic Semiconductor's nRF Connect to analyze the Calliope's bluetooth services.

The accelerometer seems to always generate an invalid, unreasonably low value for its first data point, at least when used over Bluetooth.

Here's accelerometer data being captured and charted in real time by Bitty Data Logger:

whereas here it is charting data from a micro:bit:

Here are the first few individual accelerometer notifications. As you can see, the first one has crazy values, which is what you see in the chart.

time (ms)	x	y	z
2137	-8.192	-8.62	0
2138	0.017	1.031	0.082
2177	0.015	1.029	0.089
2597	0.015	1.031	0.09
2630	0.015	1.029	0.09
2630	0.013	1.03	0.076
2677	0.018	1.028	0.089
2679	0.013	1.032	0.09
2726	0.014	1.032	0.09

Code which I can build and run on micro:bit appears to generate Out of Memory conditions (crash code 020 on the LED display) when built for and run on Calliope Mini. Here's part of the test code, which involves instantiating the three Bluetooth services Accelerometer, Magnetometer and Temperature alongside others instantiated via config.json (Event, DFU, Device Info).

int main()
{
    // Initialise the micro:bit runtime.
    uBit.init();
    uBit.display.scroll("BDL-NP 1");
    uBit.messageBus.listen(MICROBIT_ID_BLE, MICROBIT_BLE_EVT_CONNECTED, onConnected);
    uBit.messageBus.listen(MICROBIT_ID_BLE, MICROBIT_BLE_EVT_DISCONNECTED, onDisconnected);
    uBit.messageBus.listen(BDL_PIN_SELECTION_EVENT, 0, onPinSelectionEvent);
    uBit.messageBus.listen(BDL_SAMPLING_FREQUENCY_EVENT, 0, onSamplingFrequencyEvent);
    uBit.messageBus.listen(BDL_START_SAMPLING_EVENT, 0, sampleLoop);

    uBit.accelerometer.setRange(8);
    new MicroBitAccelerometerService(*uBit.ble, uBit.accelerometer);
    new MicroBitMagnetometerService(*uBit.ble, uBit.compass);
    new MicroBitTemperatureService(*uBit.ble, uBit.thermometer);

    // workaround for Calliope accelerometer service bug
    uBit.messageBus.listen(MICROBIT_ID_ACCELEROMETER, MICROBIT_ACCELEROMETER_EVT_DATA_UPDATE, onAccelerometerUpdate);

    release_fiber();
}

The Out of Memory condition arises when the magnetometer calibration procedure completes.

Using a process of elimination, it looks like the magnetometer service is the issue. I can get all the other services in place OK, but even with tweaking memory settings like GATT table size in config.json, I cannot squeeze the magnetometer service in as well, which I can on a micro:bit.

Obviously I'd expect differences between Calliope and micro:bit but I'm wondering if there are opportunities to do some memory optimisation so that code that works on micro:bit can generally be expected to work on Calliope Mini. It would be a disadvantage for Calliope if that were not the case, I think.

hi，
I encountered a problem when using the new version of calliope (name on left side below A button, '2.0' on the back-side right to the USB port)
1.When I was using calliope, I plugged into a computer with windows 7 system, the serial port driver would automatically fail to install, resulting in the serial port of my board cannot be read, but it can be installed correctly on windows 10, and the serial port can also be read.
Do you have any good solutions? Thank you！

The current implementation uses the 2G theshold and sensitivity in place for 3G which is used throughout the code. Fix this to work correctly.

Using the following functions:
uBit.soundmotor.motorAOn(30);
uBit.soundmotor.motorBOn(30);

the outcome on port B is much less than on port A

With the accelerometer service included in a hex file by including the following line of code:

    new MicroBitAccelerometerService(*uBit.ble, uBit.accelerometer);

it should be possible for a connected Bluetooth client like a smartphone to switch on accelerometer data notifications. After enabling notifications, none are ever received however.

Here's a simple test application:

/**
 * This is a simple template for use with Calliope mini.
 *
 * @copyright (c) Calliope gGmbH.
 * @author Matthias L. Jugel.
 *
 * Licensed under the Apache License 2.0
 */

#include <MicroBit.h>

MicroBit uBit;

void onConnected(MicroBitEvent)
{
    uBit.display.scroll("C");
}

void onDisconnected(MicroBitEvent)
{
    uBit.display.scroll("D");
}

int main(void)
{
    uBit.init();
    uBit.serial.baud(115200);
    uBit.serial.send("Calliope BLE accelerometer test v1.0\r\n");
    uBit.display.scroll("BLE ACC");
    uBit.messageBus.listen(MICROBIT_ID_BLE, MICROBIT_BLE_EVT_CONNECTED, onConnected);
    uBit.messageBus.listen(MICROBIT_ID_BLE, MICROBIT_BLE_EVT_DISCONNECTED, onDisconnected);

    uBit.accelerometer.setRange(8);
    new MicroBitAccelerometerService(*uBit.ble, uBit.accelerometer);

    release_fiber();
}

Furthermore, reading the Accelerometer Data characteristic always returns a value of zero. Here's a screenshot of nRF Connect showing this:

I investigated and found a clue.

There are two accelerometer drivers in the source tree. One of them creates events for component ID MICROBIT_ID_ACCELEROMETER (=4) and the other uses component ID (BMX055_ACC_ADDRESS<<1)=48.

The MicroBitAccelerometerService.cpp class registers for events from MICROBIT_ID_ACCELEROMETER but never receives any callbacks for that event.

I changed MicroBitAccelerometerService.cpp to register for events from component ID 4:

     printf("About to register for accelerometer events\r\n");
    if (EventModel::defaultEventBus) {
        int id = BMX055_ACC_ADDRESS<<1;
        printf("id=%d\r\n",id);
        EventModel::defaultEventBus->listen(id, MICROBIT_ACCELEROMETER_EVT_DATA_UPDATE, this, &MicroBitAccelerometerService::accelerometerUpdate,  MESSAGE_BUS_LISTENER_IMMEDIATE);
    }

But this made no difference. Callbacks were not received.

As an experiment, I then registered for the same events from MICROBIT_ID_ACCELEROMETER from within my main method, like this:

 int main(void)
{
    uBit.init();
    uBit.serial.baud(115200);
    uBit.serial.send("Calliope BLE accelerometer test v1.0\r\n");
    uBit.display.scroll("BLE ACC");
    uBit.messageBus.listen(MICROBIT_ID_BLE, MICROBIT_BLE_EVT_CONNECTED, onConnected);
    uBit.messageBus.listen(MICROBIT_ID_BLE, MICROBIT_BLE_EVT_DISCONNECTED, onDisconnected);

    uBit.accelerometer.setRange(8);
    new MicroBitAccelerometerService(*uBit.ble, uBit.accelerometer);

    // id =    BMX055_ACC_ADDRESS<<1;
    // MICROBIT_ID_ACCELEROMETER, MICROBIT_ACCELEROMETER_EVT_DATA_UPDATE

    int id =    BMX055_ACC_ADDRESS<<1;

    uBit.serial.printf("MICROBIT_ID_ACCELEROMETER: %d\r\n",MICROBIT_ID_ACCELEROMETER);
    uBit.serial.printf("id                       : %d\r\n",id);

   uBit.messageBus.listen(MICROBIT_ID_ACCELEROMETER, MICROBIT_ACCELEROMETER_EVT_DATA_UPDATE, onAccelerometerUpdate);

    release_fiber();
}

Now I receive callbacks in the accelerometer service class and the Bluetooth accelerometer service is working.

So, somewhere I think there's a mix up with component IDs used for events. I'm also not sure why you include both accelerometer drivers in the build. Is that deliberate or a mistake?

When using the PWM module to drive a servo motor there is some erratic movement of the motor shaft at arbitrary times. This is best observed when issuing very small increments of the motor's position, e. g. by 1°:

This happens when the update of the PWM pulsewidth collides with the on pulse. Cf. the following screenshot: The left and right impulses are the correct ones. The middle one is distorted, since it is cut short by the update of the PWM register (the left impulse is "1° shorter" then the right impulse). The yellow curve is the PWM output to the servo while the blue one is the motor supply. As you can see, 2ms after the too-short pulse the servo tries to attain the wrong pulse length.

Is this known behaviour?

I digged into the DAL but had to stop in MicroBitPin.cpp: the function MicroBitPin::setServoPulseUs() ends in a call to DynamicPwm::pulsewidth_us() which I could not locate anywhere. If someone could point to into the right direction...?

if you use the following function in the program for the first time the sensor wants to be calibrated
uBit.compass.heading()

Calibration is impossible for me, guess it is an accelerometer issue.