Cycle Analyst Android App

[Bartimaeus]

I was going to hold off posting anything about this until I had gotten farther along, but it's been over a week now and I've gotten it to work enough that I can't help but share. It's an app for the cycle analyst that currently acts as a display only. It is *VERY* basic and in its infancy: I have no doubt that there will be no end to the issues it will have. Here are a couple of screenshots:

In order to use this app with the Cycle Analyst you will have to purchase a serial bluetooth module. These are pretty cheap, here's an example: http://www.ebay.com/itm/Arduino-Wir...luetooth_Adapters_Dongles&hash=item1c26e49cce

note: I have not tested this module yet, it is on the way in the mail. I have tested the app with an arduino and a bluetooth bee module, but only because that is what was quick, easy, and in my dorm. You will have to pair with the module before you run the app.

Just to be clear and to cover my arse, the use of this app is at your own risk. I am not responsible in any way for any damages resulting from the use of this app.

here is the app file:

**edit The most recent version is here: View attachment Cycle_Dash.zip**

 

[iovaykind]

Subscribed! Can't wait to see this thing develop and mature..

What's the refresh rate on the app?

 

[Farfle]

Subbed aswell. Hopefully more things coming down the pipe too

 

[Bartimaeus]

Also thought I would let you know that I should be making a Cycle Analyst GUI for windows for one of my computer science class final projects in a couple of weeks, that should get posted here when it's done: http://endless-sphere.com/forums/viewtopic.php?f=3&t=44134

I'll be using it with 60mW xBee pros to allow for a maximum of a 1 mile range, but the GUI should also work with the same bluetooth serial module and a bluetooth usb dongle. I'm also hoping that by using the xbees for the computer and the bluetooth for the phone to be able to have both displays running at the same time. We also have to incorporate a microcontroller board made by the university, so I may be connecting it to the cycle analyst and running the bluetooth/xbee from there, with the *possibility* of adding a battery cell voltage monitor for a few cells using the analog to digital converter on board, if I can figure out how to set it up corretly. From there I should be able to read in the data from the cycle analyst, remove the end of line character, and add on the voltages of the measured cells and then send it to phone/computer. Or it may be two different screens in the GUIs, the main one for the cycle analyst data and the other for the cell voltages. Will also look into doing a low/high voltage alarm feature for the two GUIs.

If anyone has any thoughts about features, layout, etc. I'd be happy to hear them.

 

[cohberg]

Excellent work so far. I was able to get it working with my setup very quickly.

A couple questions:

• How did you envision that the bluetooth module was going to be powered? The CA's 5V output isn't quite up to the task (when in pairing mode the module uses as much as 40mA). I currently am using a couple 18650 cells with a common ground to my main pack.
• I believe that the module's logic level stuff is rated at 3.3V. I used a voltage divider to get it down from 5V to ~3.3V. Is this necessary or am I mistaken about the 3.3V limit?
• Would you be willing to release the source for the android apk? ICS renders the app funky + i'd like to code a couple additional functions in.

 

[Bartimaeus]

Excellent work so far. I was able to get it working with my setup very quickly.

A couple questions:

• How did you envision that the bluetooth module was going to be powered? The CA's 5V output isn't quite up to the task (when in pairing mode the module uses as much as 40mA). I currently am using a couple 18650 cells with a common ground to my main pack.
• I believe that the module's logic level stuff is rated at 3.3V. I used a voltage divider to get it down from 5V to ~3.3V. Is this necessary or am I mistaken about the 3.3V limit?
• Would you be willing to release the source for the android apk? ICS renders the app funky + i'd like to code a couple additional functions in.

There were a couple of ideas that I had, but I was thinking that a cheap usb wall charger would do the trick for most people. I know that Farfle used a beefed up version of a laptop charger to power his headlights, and he said that the voltage output was good down to something like 30v. You should be able to just wire up the wall charger straight to the battery pack if you're not running anything crazy high. If you have a cycle analogger you could maybe power the module off of it, although I don't have one to test. If you were feeling especially adventurous you could put in a switch for the LCD backlight and try your luck running the bluetooth straight from the cycle analyst.
I haven't had a chance to test the usb charger yet, I did the same basic thing you did with a 2s Turnigy pack for testing.

You're right about the module running off of 3.3v. The ebay link I posted is for a module mounted on a pcb that makes it plug and play for a 5v Arduino, and you can buy the boards minus the modules for about $3 as well.

I'll post the source for the app, but I don't know if you'll be able to change it using traditional means. I used MIT's App Inventor, which is a visual development environment. Once I get more time I'll try to learn how to create apps more professionally

If you do manage to work with it you should let me know, I'd be really excited if someone could help make this app more feature heavy

 

[cohberg]

There were a couple of ideas that I had, but I was thinking that a cheap usb wall charger would do the trick for most people.

Hmm I guess. Though you would still need a common ground. Don't know how happy a switching power supply would be being grounded to itself.

You're right about the module running off of 3.3v. The ebay link I posted is for a module mounted on a pcb that makes it plug and play for a 5v Arduino, and you can buy the boards minus the modules for about $3 as well.

I believe thats just operating voltage for powering the unit. I have the same board +module as you and it says pretty explicitly that the logic level stuff is 3.3 only while the power is good through 6V. Please test at 5V when you get it, I'm curious to see if it'll blow out.

If you do manage to work with it you should let me know, I'd be really excited if someone could help make this app more feature heavy

I just wanted something more ICS like + landscape. Though what I really want to do is eliminate the CA altogether (arduino + bluetooth -> android), using this as a launch point.

 

[Bartimaeus]

Hm, interesting point about the usb charger. I'll have to try that out really soon.

A landscape format is definitely on the top of the list of things to do for the app. It was okay to do portrait to get it running but it's not something I would ever put on a bike.

And I'll definitely check the module with 5v when I get it. I'm glad I went and ordered 2 modules so it won't be a major setback if I torch one of them.

 

[mvly]

Do you have the circuit that is doing the shunt calculation? Or are you just going to have something simple to do it?

 

[liveforphysics]

Awesome job!

 

[Bartimaeus]

Alright, the module arrived in the mail yesterday. I experimented with two different usb chargers. The first one that I was going to use didn't work, I'm guessing it might be because it's set up to handle both US and Euro standards, so my 66v pack is just not enough for it. The second one worked, and I hooked up the bluetooth module and didn't have any problems with the 5v TTL from the cycle analyst. I did some poking around before and found a couple of guys who had connected everything straight up to an Arduino, so I wasn't feeling too worried.

While the bluetooth module was waiting to be paired and before I hit connect in the app the red light on the module was blinking and the charge indicator on the usb end was flickering between charged and charging. The indicator went to charging after I started collecting data, so I'm going to tentatively say that this is a workable method.

Do you have the circuit that is doing the shunt calculation? Or are you just going to have something simple to do it?

I'm not sure what you're asking about. At the moment all calculations and measurements are done exclusively by the Cycle Analyst, and I'm just taking the serial output and displaying it on the phone's screen.

 

[Farfle]

Good to hear the usb charger worked on 66v.

 

[mvly]

Alright, the module arrived in the mail yesterday. I experimented with two different usb chargers. The first one that I was going to use didn't work, I'm guessing it might be because it's set up to handle both US and Euro standards, so my 66v pack is just not enough for it. The second one worked, and I hooked up the bluetooth module and didn't have any problems with the 5v TTL from the cycle analyst. I did some poking around before and found a couple of guys who had connected everything straight up to an Arduino, so I wasn't feeling too worried.

While the bluetooth module was waiting to be paired and before I hit connect in the app the red light on the module was blinking and the charge indicator on the usb end was flickering between charged and charging. The indicator went to charging after I started collecting data, so I'm going to tentatively say that this is a workable method.

Do you have the circuit that is doing the shunt calculation? Or are you just going to have something simple to do it?

I'm not sure what you're asking about. At the moment all calculations and measurements are done exclusively by the Cycle Analyst, and I'm just taking the serial output and displaying it on the phone's screen.

I see now. I thought you only had this app, and a module where you plug in the Bluetooth and to the CA modded controller. Never mind.

Great start though! Maybe I should work on something like that. It might be overall a very cheap solution.

 

[Bartimaeus]

Alright, here's a concept for a configuration screen for setting up settings profiles for the Cycle Analyst. I can't implement this by myself: the Cycle Analyst has to be set up to accept the serial from the phone and create a save from it. I'm going to ask Justin if he would be willing to add this to the CA, and I wanted to have a sample page for what I want to do for him to see.

(There would be all of the options available in a full working version, I just didn't want to take the time to make everything yet)

 

[cohberg]

Is this intended to work with V3 with slight changes or are you going to ask Justin for a V2.XX firmware that accepts configuration settings from serial? Either way, awesome.

Also you may already know this but you can enable screen rotation (by sensor) by changing screen orientation under screen1 properties.

The AppInventor interface is very easy to get up and running but has a lot of stuff hidden away. Am I correct in assuming that you are just pulling the raw string out of the CA serial stream and then forcing it to display line by line due to the locked width of the label? I tried (not very hard) to get it to separate the string out by spaces (the "split by spaces" call) so that I could have speed as a separate variable but wasn't able to.

 

[Bartimaeus]

Yeah, I was only going to hope for it to be added to the new version.

i had left the screen orientation to "unspecified" since it was rotating for me, and that is exactly what I did. The landscape mode doesn't work with the basic setup; it shows the Ah and the V on the same line, without the label for voltage next to it since it's really two separate labels.
I was having a little bit of a hard time getting it to split as well. You should try what you were doing with tabs instead of spaces, in the cycle analogger manual it specifies the output as tab delimited.

 

[hillzofvalp]

cool concept.. I would gladly switch from iOS if this was well executed. It'd be especially nice on a motorcycle for navigation anyways

 

[justin_le]

Hey super good nice work Bartimaeus. I've been waiting a long time for someone tackle this and even had some incentives back then!
http://endless-sphere.com/forums/viewtopic.php?f=5&t=13088

[*]How did you envision that the bluetooth module was going to be powered? The CA's 5V output isn't quite up to the task (when in pairing mode the module uses as much as 40mA). I currently am using a couple 18650 cells with a common ground to my main pack.

Earlier this year MRVass made up a handful of TTL->bluetooth module PCBs that had an onboard DC-DC converter with a 15-100V input range, so that you can run it from the DC battery power port that comes out standard of all the CA's now. It also happens to be _just_ small enough that you can stuff the whole dc-dc/bluetooth circuitboard inside the CA's enclosure so that there is nothing extra dangling out.

Anyways, I mention that because if someone here has the experience and skills to contribute to the app development we have a few of these modules kicking around which we could send you so you've got all the hardware handy.

It might also spur us on to pick up on that project again and bring some bluetooth module into production.

-Justin

 

[justin_le]

Alright, here's a concept for a configuration screen for setting up settings profiles for the Cycle Analyst. I can't implement this by myself: the Cycle Analyst has to be set up to accept the serial from the phone and create a save from it. I'm going to ask Justin if he would be willing to add this to the CA, and I wanted to have a sample page for what I want to do for him to see.

This _is_ on the agenda. At the moment the serial communication from the CA is purely outgoing except when you enter bootloader mode. However, it's not much of a stretch to have full 2-way communication from the normal user code so that you can configure any of the CA's eeprom settings from a 3rd party device. The only catch is that some things (such as RShunt) aren't actually stored as such on the CA, but it stores the inverse of that (conductance) in a way to minimize computational overhead when scaling the ADC data into amperage values. So in instances like that your program would have to do a bit of processing on the value before sending it to the CA.

I haven't really even started thinking about what the actual protocol would be at this stage, so there is opportunity to work this out if you have a strong idea for what's easiest. Simply mapping eeprom memory location + value is easy enough from the CA's end but not very good from your end if different firmwares versions change the memory maps.

 

[cohberg]

Eeprom memory location + value would be great as a stop gap.

Allowing "button presses" via serial would be the most bullet proof (left, right, maybe a special menu quit). This would enable remote installations with a super cheap Bluetooth tablets serving as a true remote display.

 

[Alan B]

Nice start on a Droid app. This might be one way to use the old phone if it can be loaded and used without cellular svc.

 

[Eascen]

And here I was going to use my Arduino as the item to forward CA data to my phone, since I'm using it for other things on the bike. I actually have one of those Bluetooth modules sitting here, and the 3.3v would be easy enough to replicate.

Justin: I know eeprom would be an easy mapping, but one thing the bluetooth module supports is a standard set of AT commands, such as changing the bluetooth name etc. I'm not saying this is the way to go for programming the CA, but it's a conceptual start:

http://apirola.wordpress.com/2012/09/05/setup-jy-mcu-bt-board-v1-2/

Eg:

Send: AT+BAUD1
Back: OK1200
Send: AT+BAUD2
Back: OK2400
……
1– 1200
2– 2400
3– 4800
4– 9600 (Default)
... etc

Bartimaeus, any desire to prop it up on github or the likes? Forgot to mention, I have a CAv3 sitting next to my desk, so my options are open...

 

[Bartimaeus]

The only catch is that some things (such as RShunt) aren't actually stored as such on the CA, but it stores the inverse of that (conductance) in a way to minimize computational overhead when scaling the ADC data into amperage values. So in instances like that your program would have to do a bit of processing on the value before sending it to the CA.

I haven't really even started thinking about what the actual protocol would be at this stage, so there is opportunity to work this out if you have a strong idea for what's easiest. Simply mapping eeprom memory location + value is easy enough from the CA's end but not very good from your end if different firmwares versions change the memory maps.

Doing calculations before sending them should be easy enough, I would just need to have whatever formulas you would want me to use for each thing. An example of an input value and what actually gets stored would be good to have also for testing. I'll probably do a mock up with my arduino for the receiving and storing for testing. Having an enumerated list for all of the variables that doesn't change order should make everything simple for keeping things compatible between versions. And when the format for everything is made I would post it on ebikes.ca under a category like "Development Opportunities" or something, and tell people that if they want to make an app or other type of GUI for the cycle analyst that they should follow a given format for communicating with the Cycle Analyst. I should have some kind of GUI for windows by the end of the month that I'm doing for a class final project, and from what I've heard about the development tool I'm using it *should* be as simple as compiling a copy on a Macintosh machine to get an OSX version. But that's all stuff that can be worked on later.

It would be awesome to take a look at one of those bluetooth modules, is there a thread for them somewhere? I'm also working with an old small screen CA, but that shouldn't be a problem for a while for getting display stuff going. I'll have to break down eventually and get myself a new one.

Oh, another idea I wanted to run by you was the ability to change the serial output via serial input commands, or at the very least from the cycle analyst itself. I was thinking that having a display with tabs to flip between with the various information would be a very useful feature. I'm not sure how that would change everything, but I was thinking that making a simple state machine that gets checked when the serial is printed would be relatively easy to implement. Storing the data to the phone is also a big goal that I have for the app, it isn't something that is supported with MIT's App Inventor directly but it does have the ability to use other apps and I believe that with the right apps installed on the phone you can have it run java and python scripts that could save the data.

Eascen, I have very limited experience with github, so it would be a while before I did anything with it. The zip file with the original stuff is up above though, feel free to mess around with it and do whatever you want, just share it back here with us, yeah? The dream would be to eventually get the app on to the play store as a free download, but I don't want to jinx anything yet. This is all in a very early stage.

Which reminds me, I had been avoiding using the words "Cycle Analyst App" in the actual in-app title. I wasn't sure what your stance would be on using the name or any graphics or photos from ebikes.ca, grintech, etc. But if you don't have any objections Justin I would just as soon see an app that gives credit to the people who did the majority of the hard work for us by making the Cycle Analyst. Could definitely hold off on doing any of that until a complete and stable version is out if you want to wait on putting any stamps on it.

 

[Eascen]

Just read Justin's post to the CAv3 thread, and I believe that's likely where discussion of the serial comm would go.

 

[justin_le]

It would be awesome to take a look at one of those bluetooth modules, is there a thread for them somewhere? I'm also working with an old small screen CA, but that shouldn't be a problem for a while for getting display stuff going. I'll have to break down eventually and get myself a new one.

Didn't start any threads here since we were just doing this to play around with it as proof of concept. But here is what the prototypes look like:



The one at the top has heatshrink cover and cables to plug into the existing power and communication ports on the CA. The three raw modules underneath show the actual board layout. To stuff it inside the CA enclosure, the capacitor and inductor of the DC-DC circuit need to be bend around a bit. So the plan with these units was actually to put them in a small off the shelf enclosure like the analogger and then play around with a different board layout that can more explicitly fit neatly inside the CA housing at a later point

-Justin