Dynamo Harvester Bluetooth LE w/ proprietary BT profile

[ˈpʌtaˌfɔʏfɔʏ] shared this idea 7 years ago
Gathering feedback

I recently purchased the be on bike Dynamo Harvester, a combination of dynamo hub-based power supply for smartphones and a few sensors, and would like to combine it with the map and track recording capabilities of Locus Map. The device has sensors for Speed, Barometric Altitude, and Temperature but only the first one is announced via the speed-and-cadence Bluetooth profile while the other two are implemented using a proprietary Bluetooth profile within the manufacturer’s companion application.

I spoke to the manufacturer already and they would help me or even give me the proprietary profile code they use so that I can try to integrate it with Locus Map. However, upon having a look at the Locus API capabilities, I was wondering whether that task can be achieved via another app that hooks up with Locus Map as I couldn’t find a method to add additional information—such as altitude information gained from the barometric sensor of the Dynamo Harvester device—to the track currently being recorded.

Do you have an idea of how that might be done? I’ve done Android development before and would be willing to write a plug-in if that’s the right tool for the job but so far it doesn’t seem like it.

Replies (2)


Good day,

really interesting device and glad to hear another volunteer on Android development :).

Anyway in this case it will be a little bit more complicated. Locus API is for now, made mainly to display some existing content (like points, tracks) directly on a map or handle with existing points inside Locus. What you need is some injection of extra information into running track recording. Also in your case, such extension will needs a quite a lot of work on your side with handling of Bluetooth connection to device and all the stuff around.

Speed & Cadence profile is already working for you in Locus, did you tried it?

All such extra data are stored in "Location" class: https://bitbucket.org/asamm/locus-api/src/352773c893a1acb93033d79286194d4fb1997bdd/src/locus/api/objects/extra/Location.java?at=default&fileviewer=file-view-default . In "ExtraSensors" container is now possible to store temperature value, but only one type of altitude value is now supported.

So I'm always glad if someone active wants to do some improvements and create some nice add-on etc. , but in this case, I think it should be 100times more work for you to create all around (plus for me to extends API), then to add a few lines of code in existing BT handler and add support for two special profiles for this device. With temperature, it won't be a problem. With Altitude, it depend if it is an absolute altitude value (how it is calibrated?) or some relative value.

So what you think?



that’s the feeling I got when having a look at the API—it looked more like what you described than what I would need in this case.

S&C should be working, I guess, I just haven’t tried it yet. But I read a post on a bulletin board where someone described how to use the Dynamo Harvester together with Locus Maps and it worked for him.

The ExtraSensors class looks good so far, although it would be better to have two altitude values to work with. The companion app for the device—according to the manufacturer—uses both the GPS altitude as well as the barometric altitude of the device, preferring the barometric value for accuracy reasons. I have yet to see the source code to see how exactly it assesses which value to use, though.

Temperature would be more of a nice-to-have feature and I would rather like to see the altitude work first, as it’s more important to me—although the temperature value would, of course, be interesting as well when using the live broadcast feature of Locus Map track recording. :)

I’m not sure which kind of altitude sensor it is. If it’s absolute, I guess that’s what the app uses GPS for: to calibrate the initial value. I think I have read that somewhere, too, but I cannot find it at the moment.

So did I understand you right that you would be willing to implement the profile for this special device into the core application? That would be awesome!



fine. Secondary altitude should bring extra load to Locus, but such parameter should be needed really rarely (only in this case). So I may only offer direct implementing into Locus if I get specification for these profiles, but:

- received altitude will be set to only single "altitude" parameter that exists in "Location" class

- temperature will be set to "temperature" filed in extra container (usage of this parameter is anyway quite, well, ... it's only exported to GPX files, otherwise it's not visible in Locus).

So this is best I can offer for now :).


Locus Map already offers the usage of a smartphone’s barometric sensor—I guess you are solely using that one in case the smartphone has one? I tried to find a way to mock smartphone altitude sensor data by using the Dynamo Harvester’s data of the altitude sensor but could only find ways to mock gps coordinates; it doesn’t seem like other data can be mocked on actual devices, i.e., not Android virtual machines for development.

I will write to the manufacturer and ask then. What exactly would you need?


Barometric sensor is used when you allow it inside "Altitude manager" feature. Anyway barometric values are not stored, but instead directly used to modify elevation values.

About "what I need to know"

If I'm correct, then to read correctly any data over BTLE, it's needed to know UUID of certain characteristic and also structure of data.

- UUID is just a text that identify source

- by structure I mean - data are load as byte array (byte[]), so I need to know, what is inside


My name is Thomas and I am the developer of the Bluetooth firmware of the Dynamo Harvester. We would be glad to see support for our Dynamo Harvester in Locus Map. If you are intending to adapt the Locus Map software to the proprietary Dynamo Harvester Bluetooth profile we would give you all info you need and we would send you the Dynamo Harvester hardware for testing.

The Dynamo Harvester implements the CSC profile, of course, but this profile cannot carry high-resolution data of speed and distance; altitude is completely out of scope of this standard profile.

You would need to implement the following steps:

  • Search for CSC sensors
  • Check all CSC sensors for the availability of our proprietary profile
  • If our profile is available, register notifications for this profile. Do not register or use the CSC profile, because our profile is a superset of CSC.
  • With every notification you get the absolute number of dynamo events and the time of the last event. Additionally you get barometric altitude (not calibrated) and temperature.

What do you think? Does it make sense for Locus Map?


Good day Thomas,

I'm glad to see here someone qualified from this interesting project.

I also think that cooperation here should be really interesting and mainly useful. Locus is made mainly for hike and BIKE and number of users is quite high, so there definitely will be more interested users then "just" Patta who started this topic.

Anyway as I'm more basic BT developer, implementation is possible only with help from your side. So if you will be interested, please keep in mind that I'll have more questions in case, something won't work :).

So generally, if you may be able to give me some sample codes, I'll gladly add support directly into Locus.

Second question is anyway - what data Locus may get from your device, that will be useful for user and in cases they are not yet fully supported in Locus, how to handle with it. As I see on your page with specifications: https://www.be-on-bike.de/en/harvester/specifications.html , there exists:

- "distance" - Locus do not handle measured distance in any cases as distance is already measured from GPS coordinates

- "altitude" - here it may be interesting as correctly calibrated barometric altitude is a lot more precise that measured GPS altitude

- "temperature" - interesting parameter that Locus may record and export to GPX files

So, if I'm correctly, only interesting here is altitude value, which I'm not 100% sure if it worth it.


I’d love to see the increased accuracy that the barometer brings. I understand that including the dynamo’s speed date for increased accuracy especially in tunnels and so forth won’t be possible but I would very much like to have the altitude values of the DH included.



I'm also using the dynamo harvester and locus, and it's great to hear that you consider to support for the DH sensor values. Additionally to the 3 sensor values the device seems to send information on the battery state that would be useful to be displayed in dashboard.

Leave a Comment
Attach a file