calliope-mini / microbit-dal Goto Github PK
View Code? Open in Web Editor NEWThis project forked from lancaster-university/microbit-dal
Calliope mini - DAL
Home Page: http://lancaster-university.github.io/microbit-docs
License: Other
This project forked from lancaster-university/microbit-dal
Calliope mini - DAL
Home Page: http://lancaster-university.github.io/microbit-docs
License: Other
Hi,
I'm actually testing some bluetooth services and am experiencing several problems. Some of them are already known.
Accelerometer data over BLE does not work
As reported by @smartyw in #7.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.