# Looking for 3rd party software developers for Soliton



## Qer (May 7, 2008)

I'm trying to find those doing 3rd party software for the Soliton but so far I've only found EvDash, an Android app that draws a dash board using the logging data from the Soliton. Why I want to find them is because I'm considering pretty major changes to the whole network handling in the Soliton where the http-protocol will be extensively rewritten in 1.5 and I might take a serious stab at a more designed (rather than evolved) logging protocol in a future release.

The reason for the changes in the http-protocol in 1.5 is because that Big Sol makes a valet mode rather necessary (since you probably don't want transmission twisting torque when you're driving on ordinary streets...) and since a valet mode will require some major changes in the web and parameter setting code I can as well take the opportunity to clean that rat nest up. It's been an ongoing project since release 1.0 to improve the code in all possible ways and, well, seems the web server is next on the agenda (again, actually). 

The reason for the changes in the logger protocol is because logger was initially just intended for internal use or possibly for helping customers pin-point problems, which is the reason that protocol is a bit, err, messy and ad hoc. I had no thought about future expansions etc which is why there's the current mess where you have to run the right version of logger for correct logging output. So I would like to formalise it more and also prepare for other future products so they can share the same protocol, which means there's a need for both flexibility and the possibility to identify what kind of device that's transmitting etc.

Anyway, that means that if there's any software out there that uses the network to communicate with the Soliton in any way those will stop working and that's why I want to get in touch with the responsible people, both to be able to give a heads up what's going on but also for feedback and suggestions to hopefully not having to change things too much again in the future.

Sooo, help?


----------



## Salty9 (Jul 13, 2009)

Have you checked http://www.janspace.com/b2evolution/arduino.php/2010/06/26/scooterputer?


----------



## JRoque (Mar 9, 2010)

Hello Dr Q. How about a feature where the app sends a string to turn bits on/off depending on what they need in the protocol. For example, upon startup, the Sol-x will have a standard protocol that puts out all the vars. But it's ready to receive a parm that switches off those things the app doesn't need, like how many motors the controller has killed, etc.

From there on, any new features added to the protocol will be added to the end of the stream so current apps continue to work fine with what they know and ignore the rest. 

- An app needs motor volts, amps, rpm and temp. That's parms 1, 2, 4 and 10 so they send "$Gimme,1,2,4,10#"
- The controller is then set to send "$1,2,4,10#" back and skip the rest.
- The app needs to request this every time it starts since its a volatile setting
- You add a feature to the controller that can now report temperature in C degrees. You leave parm 10 (temperature) as is and add the new one to parm 11. If the app is ever upgraded, it can use it but if not, it will continue to work fine as is.

I'm going to stop here and see if I'm going down the right track since I have a feeling I completely misunderstood what you were asking for 

JR


----------



## Jozzer (Mar 29, 2009)

I was going to start work on a Labview program to view/record data, I'll wait till of firmware before I start..


----------



## Qer (May 7, 2008)

Salty9 said:


> Have you checked http://www.janspace.com/b2evolution/arduino.php/2010/06/26/scooterputer?


He doesn't really seem to target the Soliton controllers...



JRoque said:


> I'm going to stop here and see if I'm going down the right track since I have a feeling I completely misunderstood what you were asking for


No, it's a very interesting idea! First I thought that it's extremely complicated and that the CPU in the Soliton might not be beefy enough to handle it, but I'm not so sure it'd be that impossible, really. Biggest obstacle would be changing the behaviour from one directional communication to bidirectional, right now the Solitons only broadcast the info and doesn't care if anyone tries to reply. I'd say that the logging would stay on the current port and keep being one directional and the commands would have to be sent on a different port, otherwise two Solitons on the same net could easily DoS-attack each other which would be embarrassing... 

I have to ponder it. The idea is definitely not without merit, provided it doesn't get too complicated to implement in the Solitons.



Jozzer said:


> I was going to start work on a Labview program to view/record data, I'll wait till of firmware before I start..


You might have to wait for a while then. As I said, the log protocol won't change until earliest 1.6 and considering how often we (don't) release new software that will probably be something like a year.

My recommendation would be to simply keep in mind that the protocol will be changed (which it has been a few times already, although not from scratch like this) and make sure there's an API where the actual UDP data parsing can easily be replaced later.


----------



## PhantomPholly (Aug 20, 2008)

As Issac Asimov once said, "Two is a ridiculous number."

What he meant was that generally there are only 3 meaningful values - 0; 1; and "many."

If you are going to enable a Valet mode, why not just parameterize your configuration and allow multiple configurations to be stored? Then, just "point" to the set you are using. That could include racetrack; street - performance; street - energy conserving; and actual valet (limited to 5mph!!!) plus any others you can think of.

Next, simply add a USB port and software stack to handle a USB mass storage device. Save all your logging to a rolling log set of files (changing over every hour, or whatever makes sense. Put your configuration settings there, and simply have the controller load the current set into memory when operating. Now, all the brains of the controller come out when you pull the USB stick, which costs nearly nothing. Then let people manage the raw data however they want - it isn't your problem any more.

FWIW.


----------



## Anaerin (Feb 4, 2009)

As you're already using HTTP for the configuration, why not extend that?

Client sends: GET /logging/GetCounters
Server responds with a JSON object declaring which counters (what logging detail) is available. For instance:
[
{"Name": "RPM", "Description": "Motor Speed in RPM", "Type": "integer", "Minimum": 0, "Maximum": 10000},
{"Name": "TmpC", "Description": "Controller Temperature", "Type": "integer", "Minimum": -50, "Maximum": 150},
{"Name": "TPS", "Description": "Throttle Position", "Type": "decimal", "Minimum": 0, "Maximum": 1},
{"Name": "SPD", "Description": "Speed", "Type": "integer", "Minimum": 0}
/*...and so on */]

Client only needs to do this once.
Client then requests the data it wants: GET /logging/GetLog?Counters=RPM,TmpC,SPD&Interval=100
Server responds:
{"SPD": 1, "RPM": 10, "TmpC": 55, "TimeStamp": 2011092115100820};
{"TmpC": 80, "SPD": 74, "RPM": 1500, "TimeStamp": 2011092115100920};

...And so on, as long as the connection is open. The items can be in any order, not necessarily the ones specified. If the client wishes to change what's being reported, it closes the connection and re-opens the connection to /GetLog with the new counters.

Using this as a framework would make it very extensible and reliable, and able to be used in virtually anything. It would also mean if new counters or capabilities were introduced at a later date, it wouldn't break compatibility with existing clients. It also means that clients can be dynamically configured to show what their users want, with well-defined ranges and descriptive names for each available counter.

It also means, if they want to monitor the system from a laptop or something similar, an AJAX-based frontend can be provided incredibly simply too.


----------



## skooler (Mar 26, 2011)

Hi Qer,

I will most definately be purchasing a Soliton 1 or Junior for my project when the time is right. I want to present something you may (or may not!) wish to consider.

I am an IT consultant and dealing with logging protocols is something I do every day.

"Syslog" is a protocol used by a range of networking equipment that I regurlarly use. I have seen it in small unbranded hubs, printers to large Cisco firewalls and routers, so I guess the Soliton would have the power to use it.

Syslog effectively streams the log data to an external device (often a pc but there are android and iphone apps that can be used) which can then do what it likes with the data. For me this is often producing graphs, statistics, searching for anomolies etc. 

One of the big advantages is that it pulls the processing away from the soliton and no logs would need to be stored 'locally' as they are stored and processed on the syslog server (pc/tablet/smartphone). This would free up space in the solitons memory (I am sure I read its running out of space and your using CSS to help with this somewhere?)

As these devices can already act as a syslog server (i.e. display logs) I see no reason why this couldnt be used to drive an RPM meter or view controller temperature on a smartphone/tablet/pc application.

I would of thought a home or office router you may have access to will have a syslog feature you may be able to play with to get an idea.

Thoughts?


----------



## Brute Force (Aug 28, 2010)

Qer,

Sent you a PM.

BTW- I just updated to firmware v1.4 in my Solitons. Easy and quick. You guys did a fantastic job!


----------



## evlowrider (Jul 23, 2009)

Hi QER

I wrote the EV Dash Android app for the Soliton1. I'll send you a PM. 

Pete.


----------



## skooler (Mar 26, 2011)

Hi Qer,

I would be willing to work with yourselves and any others that are interested in order to create a new app if/when required.

I also want to add that I think it would be really good if there was an off the shelf touch dashboard for the Soliton. For example, a small box that plugs into the Solitons ethernet port (a wireless router) and a tablet type device or touch screen that can be mounted on/in the dash.

This could then be used to display and control:

Motor and controller info (temp, rpm volts amps etc) as it does with evdash/evspeedo.
SatNav
BMS info?
Charge state
Range
radio, cd and play audio from flash
others?
The routers built in hub/switch could then be used to connect to more than just the Soliton. For example a bms could be plugged in and the data displayed on the screen/tablet (doesnt a member on the forum make a bms?).

I think that this could be quite an attractive package. The way I see it is if there isnt anything available when i'm at this stage of my build, I will have to make it myself. So I may as well offer to help so there is something available!

Cheers,

Mike


----------



## dtbaker (Jan 5, 2008)

I mostly just do small applications for server-side databases and dynamic interfaces using basic HTML, perl, and prototype on a local host server. The combination of a localhost, perl, and standard html might be all you need. perl supports some remarkable APIs for Berkley databases and tons of free open source modules that do just about anything you can dream up. In case it comes in handy for you guys, I thought I'd let ya know:

http://www.xitami.com/ - provides a small, fast, self-contained server that can be set p to be a stand-alone localhost. runs perl, etc

http://www.gumstix.com/ - builds TINY standalone computers on a chipset about the size of a pack of gum that can be preloaded with Linux, a localhost webserver, perl and whatever else you need.

D


----------



## gjposner (Feb 27, 2012)

Horribly sorry for raising the dead, but I too am looking for a way to monitor a Soliton 1. I live about an hour from EvNetics and have visited their shop, even viewed some prototypes (all I can say is DAMN!). My brother and I will be putting a Warp 9 with a Soliton 1 and a small armada worth of lead batteries into an open air vehicle and we want a way to monitor it on the fly without the needs of a computer. This vehicle is open to the Florida elements so whatever we use will need to be water-proof and we are able to make it theft resistant from there. We were going to go with a Netbook connected to the ethernet port on the Soliton, but we are concerned about long-term humidity exposure. We will have compartments to store the computer, but I honestly prefer something I can just put in the car and be able to view it in any weather.

We already have a speedometer, ammeter, and volt meter, courtesy of Speedhut. The speedometer is GPS controlled, check it out, it may be an easy answer to people looking to just measure speed. We got the 160mph with 8k tach to also monitor the Warp, but we want a way to log everything as well as change parameters on the fly so if we let someone drive it and they stab the throttle we do not blow something as well as dial down the amperage for highway driving. I can provide more info regarding the vehicle and our hopes for it along with why later if anyone cares (if not, no worries).

I have absolutely 0 experience programming arduino's and have never worked with one and the concept of doing so is a bit intimidating as I am not the most programming savvy person out there. I would really like a basic unit that is completed, plug and play kind of thing, but I am willing to work with whatever I can get, learning if I have to.

I am happy to talk to the EvNetics guys and see if they have any suggestions and report back, but I am so far impressed with the controller.. Doing runs in their Porsche really solidified the power of that controller, and seeing the filter caps in the prototype showed me they are not screwing around when it comes to these things.

Thanks,

-Grant


----------

