Gotway/Kingsong protocol reverse-engineering

[Tilmann]

Did you have the time today to go out for a ride and see if the numbers look plausible in real situation?

Hi Esa, sorry, not really. Had plans for joining the "Skater Night" and drive 30 km through the city (with police escort ), but that got drowned by thunderstorms. So I went just a few hundred meters through light rain. I had a feeling, that speed showed a bit high values, but could not compare it to a GPS display, so that's too shaky of a result. 

Cross fingers for better luck tomorrow.

[esaj]

Hi Esa, sorry, not really. Had plans for joining the "Skater Night" and drive 30 km through the city (with police escort ), but that got drowned by thunderstorms. So I went just a few hundred meters through light rain. I had a feeling, that speed showed a bit high values, but could not compare it to a GPS display, so that's too shaky of a result. 

Cross fingers for better luck tomorrow.

No worries. Not sure why the speed would show too big values, but anything's possible  Just a little bit concerned, I better not build a vibration-version for vee73, until I know the values are correct, I don't like the idea that the vibration should set off just below the cut-off speed, and then it would measure the speed wrong

Didn't get to ride much today myself either, although the weather has now been fine, mostly I've been sanding & washing wall boards and undersides of eaves (up until around 12am), as I better get the paint job done before the rains start again    

Oh, I did visit one of our forum members today (ijnx), who lives nearby, he wanted to test-ride an EUC. The original idea was that he'd test the 14" generic, but since it's still on loan with my father-in-law, I let him test the Firewheel. Didn't do that bad, he actually learned to mount it... well, not every time, but he could get on it and ride a few meters at a time, still over 10 meters at best, and even turn a little.

[Tilmann]

No worries. Not sure why the speed would show too big values, but anything's possible  Just a little bit concerned, I better not build a vibration-version for vee73, until I know the values are correct, I don't like the idea that the vibration should set off just below the cut-off speed, and then it would measure the speed wrong

Yikes - what? Now we're both supporting vee73's candidacy for the Darwin Awards? 

In that case: speed shown by your app is precisely 15% too low!! Make sure to include that correction factor!!

(I much rather like to hear your story about winning new members for our community than loosing one to a damned Finnish tree stump) 

[esaj]

Yikes - what? Now we're both supporting vee73's candidacy for the Darwin Awards? 

In that case: speed shown by your app is precisely 15% too low!! Make sure to include that correction factor!!

(I much rather like to hear your story about winning new members for our community than loosing one to a damned Finnish tree stump) 

Yeah, why make faster wheels, when we can just inflate the numbers in the apps?   "You're riding 100km/h currently... that bike that just went past you was going 150km/h..."

I was contemplating with the idea of correcting the error in speeds reported by Gotways (which is said to be around 3km/h in the higher speeds, so probably around 10% too much), but that's going to take some precise measuring and comparing to a bike computer which, AFAIK, is the most trustworthy way to measure the real speed (not taking into account high-cost professional measuring devices). Don't know if Kingsongs have the same fault. In general, the idea of reporting the speed directly from the wheel is a bad idea, accurate motor rpm (or rps, rounds per second) would be more useful, as the user could then enter the measured circumference of the tire into the app (or if they don't want to measure it, just pick default value for the wheelsize, ie. 16" => 1272mm). I guess the idea with the Gotway app & reporting the speed directly from the wheel has been that the app should be useable by end user without any configuration, as it works the same with 14" and 18" (and others?)...

 

Edited August 16, 2015 by esaj
Gotway, Kingsong... same difference... ;)

[Tilmann]

I was contemplating with the idea of correcting the error in speeds reported by Gotways (which is said to be around 3km/h in the higher speeds, so probably around 10% too much), but that's going to take some precise measuring and comparing to a bike computer which, AFAIK, is the most trustworthy way to measure the real speed (not taking into account high-cost professional measuring devices). Don't know if Kingsongs have the same fault. In general, the idea of reporting the speed directly from the wheel is a bad idea, accurate motor rpm (or rps, rounds per second) would be more useful, as the user could then enter the measured circumference of the tire into the app (or if they don't want to measure it, just pick default value for the wheelsize, ie. 16" => 1272mm). I guess the idea with the Gotway app & reporting the speed directly from the wheel has been that the app should be useable by end user without any configuration, as it works the same with 14" and 18" (and others?)...

Ok, ok, here's the plan: Sometime this week I'll go back to Tempelhofer Feld

That blop you see on the lower right of the map, is a former airfield, now turned into a public playground. It features two long runways and not one tree anywhere close to distort GPS signals. 

I will try to run up and down those runways with different speeds, trying to keep them as constant as I can manage for at least 1 km. While doing that, I will simultaneously record with your app and OpenGPStracker. That should give us fairly exact data. I can also measure the circumference of my 18" tire and use high tire pressure.

Don't hold your breath though - weather forecast doesn't look too exciting. And I need a low winds day, too. 

 

[esaj]

Ok, ok, here's the plan: Sometime this week I'll go back to Tempelhofer Feld

That blop you see on the lower right of the map, is a former airfield, now turned into a public playground. It features two long runways and not one tree anywhere close to distort GPS signals. 

I will try to run up and down those runways with different speeds, trying to keep them as constant as I can manage for at least 1 km. While doing that, I will simultaneously record with your app and OpenGPStracker. That should give us fairly exact data. I can also measure the circumference of my 18" tire and use high tire pressure.

Don't hold your breath though - weather forecast doesn't look too exciting. And I need a low winds day, too. 

Sounds like a good plan. And no rush with it, I'll probably be busy next week, especially if the batteries finally arrive, I'd guess it's going to take me something like at least 2-3 days to completely tear down and rebuild the Firewheel with all the extra wire channels, rewiring, rubber seals & lock washers, changing the mainboard metal plate, voltage & current measurement with external powering (9V battery), maybe separate voltage displays for 2 different battery packs (only got 2 extra displays), kill-switch for speaker, soldering battery connectors, resealing and whatever else I come up with, plus the house painting, familiarizing myself with Android more etc. etc., so I've got a lot on my plate any way

[esaj]

I now have vee73's Gotway MCM2s, and have done a few tests with the original Gotway-app and the prototype. It looks like the speed values match and I get the data out as expected, although I need to test the wheel more still. I'm also in the process of building a new prototype of the app, this time more properly, ie. not just building it on top of the existing BluetoothChat-example. Although, I'm still using lots of code snippets from the original example, as I've still got ways to go to with learning Android.

While at it, I connected the original Gotway-app to my simple "fake" bluetooth-server application, to see what the commands are. The "b"s denote just beeps, they are used to make the wheel beep after the command, the actual command is the previous character (bolded):

Tapping the loudspeaker icon apparently makes the wheel beep, also there's Ring five seconds under the menu, which sends 'b's to the wheel for 5 seconds:
b

Madden mode:
h   
b

Comfort mode:
f
b

Soft mode:
s
b

View current (I don't know if the wheel needs this, the data captures I've had so far always have contained the current-information):
m

Turn off level 1 alarm:
u
b

Turn off level 2 alarm:
i
b

Turn on speed alarm:
o
b

 

Calibrate (the first character's a comma, it might be that only the first c y -pair is needed, or maybe all of them...):
,
c
y
c
y
c
y

 

There's still 'n' -command in the code, but I don't know what it does, it looks like it could be continuously sent to the wheel at some point, but I haven't figured out the logic which does it (at least yet).

Edited August 28, 2015 by esaj

[esaj]

Here's the "next gen" version, coming along... the UI still looks like s*it (I'm not much of an UI designer), but I think it's better than the one I built on top of the chat example:

I planned it for much smaller screens though   This screenshot's taken from a 10" tablet. That's actual live Gotway MCM2S data being shown, the graph shows the electrical current  (and no, I didn't need to send the "m"-command to it), first the less spiky graph is the wheel spinning freely in air at different speeds (requires next to no power, so the current is fairly steady, even running at 30km/h+), then the spikes are me moving the wheel back and forth on the floor by hand. Finally I set it between my legs to get my both hands free to take the screenshot (power button + volume down simultaneously). The graph needs visible scale values, it's actually near the 0-line at the end and the beginning is in negative zone... I don't remember if they were there earlier with the lighter theme, maybe the texts are also black now or something   Also it crashes if I turn the tablet to landscape... so much to learn still

[esaj]

A few hours of work with the UI and I finally got it to stage where it's semi-useable with a small screened Android-phone that vee73 sent with the wheel. It came with a small case that can be attached around arm or wrist, I just put it around my wrist guard. I went out and shot a video by holding an iPhone in my other hand, not exactly easy, but doable. I then just slapped the videos together in the Youtube Video Editor:

 

 

The first 25 seconds is just connecting to the wheel (I couldn't tap on the screen and hold the iPhone to show it at the same time with just one hand ). After it connects, the texts change to show the values the wheel is sending. The graph is showing the voltage until I change it to show the power later on (around 1:26). I then headed up the street, going up a slight uphill most of the time, shooting the screen of the phone and trying to watch the values at the same time (and yet look at where I'm going in-between ) until about 1:13. Then I accidentally stopped and restarted the video recording   Then I stopped recording again, and rode to the end of the street. At around 1:26 I'm at the end, and had to get the phone out from the case, as I couldn't hit a badly placed drop-down menu (that controls which value the graph is showing) through the case... The UI still needs a lot of tweaking for small displays. I changed the graph to show the power (calculated simply as voltage * current), and rode back down. Mostly the power required while going downhill was much, much lower than when going up, but I did a few stronger brakings on the way down to see how high the regenerative power goes with them. I don't know if the values are all 100% correct yet, I think it went up over -1700W (regenerative) at some point

@Jason McNeil could probably comment on the power values, as he's done more testing with the Kingsongs, are these values plausible?

Edited August 29, 2015 by esaj

[Jason McNeil]

@esaj, you're beyond pure genius! That's damn impressive, probably the most impressive thing I've seen posted on the forum! I'm going to try to put you in touch with King Song, I think there's a pretty good chance they'll be interested in tapping into your expertise, look at their attempt by contrast.

  

Edited August 29, 2015 by Jason McNeil

[Gimlet]

Is that their new app for the new ios compatable board @Jason?

[Jason McNeil]

Yep.

[esaj]

@esaj, you're beyond pure genius! That's damn impressive, probably the most impressive thing I've seen posted on the forum! I'm going to try to put you in touch with King Song, I think there's a pretty good chance they'll be interested in tapping into your expertise, look at their attempt by contrast.

Thank you kindly, but this is my first venture into building Android-apps (my working career has mostly revolved around server backend-systems), so I'm hardly a professional at that, I'd expect them to have better mobile-coders themselves (although, if the new one's done similarly as the last one regarding especially binary data reading, they too have a lot to learn still )... This prototype is still very much that, a prototype, and has lots of issues to solve yet, like how to keep the app running in the background if the user switches to another app, or a call comes in, different layouts for different screen sizes, a few other features, bug hunting etc. Vee73 wants a version that has the vibration-alarms at very near to cut-out speeds, so I have to be careful and try to check that it works in all those situations, it would suck if the app would go to sleep in the background or something, and stop giving the alarms.  

You didn't comment on the power-values, do you think they're off or plausible? At first I'm going up a slight uphill, so I'd expect it to require more power, but still the wattages seemed somewhat high... also the regenerative braking was spiking to 1700-1800W range. Maybe I'm reading the current-values wrong (too high), the voltages seem right.

 

Is that their new app for the new ios compatable board @Jason?

If the new Kingsong app isn't compatible with older wheels, it probably means they also changed the protocol... Needs to be reverse-engineered   Also, I haven't got the skills or tools to build iOS (iPhone/iPad) -apps, as I don't know Objective-C (the language used in iOS) and building the app needs a Mac. I hate the Apple you-build-the-apps-with-our-products -system, the long wait of releasing app etc...   Real-world scenario that has happened to us at work and more than once: app is submitted to iTunes (the Apple app-shop -thingie), waits a couple of weeks for review, then is rejected due to some very small cosmetic issue that's fixed in 5 minutes, then resubmitted and it another couple of weeks of waiting before it's accepted and can be released in their store  

Edited August 29, 2015 by esaj

[Tilmann]

  

Hi @Jason McNeil, the app GUI sure looks nice at first glance and would be a good improvement compared to the ones I have seen so far.

Looking a bit closer, it shows a funny collection of beginners usability and photoshop fails: 

• The color shading behind the Mileage and Speed numbers make the actual values hard to read. Any decimal point or comma would be lost in the dark...
• The use of the shadows looks like the developer just discovered a new filter: Way too much of a good thing. And: shadow results from light. With the watch faces, the light sits at the top center and the shadows are blurred, with the "Voltage", "Current", etc. text labels, the light is at the top right (blurred), for the "KM / H" label, light comes from the top left (crisp), the thermometer doesn't cast a shadow at all, the gear wheel on the settings button has the light coming from the lower right. The suggestion is obvious: choose one global light source and position a subtle shadow accordingly.
• The whole design is cluttered with too long text labels. Suggestion: use "Volt" instead of "Voltage", "Mode" instead of "Ride Mode", "Trip" instead of "subtotal Mileage", etc.

Interesting on the side: The app seems to be able to show settings presently active on the wheel. From what I understand from @esaj's analysis of the Gotway BT protocol, it does not support a query from the app to the wheel to return current settings - you can change Ride Mode, but it can't show you the Ride Mode the wheels is using now. That's a big improvement also, but likely comes for the price of a new protocol incompatible to Gotway's.

 

Edited August 29, 2015 by Tilmann
typo

[esaj]

Hi @Jason McNeil, the app GUI sure looks nice at first glance and would be a good improvement compared to the ones I have seen so far.

Looking a bit closer, it shows a funny collection of beginners usability and photoshop fails: 

• The color shading behind the Mileage and Speed numbers make the actual values hard to read. Any decimal point or comma would be lost in the dark...
• The use of the shadows looks like the developer just discovered a new filter: Way too much of a good thing. And: shadow results from light. With the watch faces, the light sits at the top center and the shadows are blurred, with the "Voltage", "Current", etc. text labels, the light is at the top right (blurred), for the "KM / H" label, light comes from the top left (crisp), the thermometer doesn't cast a shadow at all, the gear wheel on the settings button has the light coming from the lower right. The suggestion is obvious: choose one global light source and position a subtle shadow accordingly.
• The whole design is cluttered with too long text labels. Suggestion: use "Volt" instead of "Voltage", "Mode" instead of "Ride Mode", "Trip" instead of "subtotal Mileage", etc.

Interesting on the side: The app seems to be able to show settings presently active on the wheel. From what I understand from @esaj's analysis of the Gotway BT protocol, it does not support a query from the app to the wheel to return current settings - you can change Ride Mode, but it can't show you the Ride Mode the wheels is using now. That's a big improvement also, but likely comes for the price of a new protocol incompatible to Gotway's.

 

I'm not an UI-designer nor graphician, but the new Kingsong GUI does look messy and somewhat hard to read on a glance (I personally prefer just to see the speed etc. as numbers, instead of gauges like that)... I went for simple design myself, speed & wattage with big font, other less often needed data smaller, black background and bright green texts etc. The idea was that it won't glare too much to your face during night, yet is easily readable and at least on oled-displays, I'd expect it to use less power as there are not that many bright pixels (afaik, the brighter the pixel, the more power it consumes from the phone battery on oled-displays, with backlit-displays it doesn't probably matter).

The graph is a bit gimmicky, as you probably won't look at it that much during riding, the base case where this started was Hobby16's telemetry hardware -project (although hobby hasn't been around for a couple of weeks, don't know what's going on with that), and the idea was that you could record the data for later inspection, yet see the graphs on the go too... Will have to see what I do with that, maybe make it hidden by default and add a button to show it if you want to inspect it while riding or something. Then all the other data could use more screen space with bigger, easy to read font.

[Jason McNeil]

Gimmicky fiddlesticks, I think it's brilliant IMO this is the first eWheel App that shows promise of being semi-useful. An instant power reading, like Ninebot's is completely useless, as it jumps around all over the place. The minimalist night-vision mode is great. Will the App be able to store the data for later analysis? 

On the deficiencies of the future KS App, well let's just say they're pretty self-evident. This was from about two weeks back, so maybe it's improved since then...  

Question about the regen power: a limitation of the data-logger is that there is no reverse capture, so haven't been able to record this.

[esaj]

Gimmicky fiddlesticks, I think it's brilliant IMO this is the first eWheel App that shows promise of being semi-useful. An instant power reading, like Ninebot's is completely useless, as it jumps around all over the place. The minimalist night-vision mode is great. Will the App be able to store the data for later analysis? 

Yes, this was already done in the earlier prototype that used the BluetoothChatExample-UI, when the record-button is hit, it starts logging the data in CSV (comma-separated values)-format, that can be read by Excel and many other graphing softwares. When the user hits the button again, the app asks under what name the log is to be saved (well, it's already written at that point with default name, like wheelemetrics_log_<dateandtime>.txt, so basically the user just renames it). The reason I'm streaming it directly to file to is that the data is not lost even if the app crashes (it's still there to the point of crashing). Of course the app should never crash, but just to be on the safe side    That's what Tilmann used to record the log captures to me so I could compare them against GPS-readings (in a private conversation, it's not in this thread).

On the deficiencies of the future KS App, well let's just say they're pretty self-evident. This was from about two weeks back, so maybe it's improved since then...  

Question about the regen power: a limitation of the data-logger is that there is no reverse capture, so haven't been able to record this.

Ok, I guess it could spike to pretty high values during stronger braking and accelerating uphill, was just wondering if the values were badly off (I think MCM2s has 500W rated motor, so was just wondering if the 700+W going uphill was "normal" or if the wheel/app sends too high values). I'll try to make a longer trip (without shooting any videos) today at some point to see it in more varying situations, right now I'm soldering some more battery connectors...

[esaj]

Finally got some more work done on this, mostly related to the adjustable vibration-alerts that vee needs. Today, so far, I've managed to get the vibration-background service to work so that the speed data is read & vibrations work even if the app is in the background (so incoming call or such shouldn't stop it from working). Also worked on retrying a lost connection (if the BT-connection is dropped during riding, the scary thing is that it takes something like 15 seconds before the connection loss is recognized, might need some sort of timer that acts if data is not received for a few seconds), and it seems to work ok at least as long as the app is on the foreground, still need to test it if it's in the background. And of course if the application gets killed completely, I doubt there's much I can do. Currently also the vibration service doesn't die properly with the app but keeps running in the background (although doing nothing, as it only wakes up to check & change the vibration parameters on speed data broadcasts).

While Android isn't that hard to work on otherwise, the API is pretty large, and I'm probably doing some things in an unnecessarily complex way, as I don't know better (yet)   Also some showstoppers have been things like IntentService losing all its state between handleIntent-calls (it's actually recreated silently, which is just stupid imho) and BroadcastReceiver not receiving anything, because I missed some details on how to use it, perplexed me for about an hour (you either have to define an intent-filter in the manifest for it, or set the receiver-class in the Intent directly, otherwise it's just silently thrown away)... Good thing we have StackOverflow, where people usually explain things better than Android documentation   

I have a very simple UI done for setting the speed limits (only two limits currently, but the underlying architecture doesn't really prevent from using a larger number of warnings, each with their own vibration-signature), but so far I haven't started to add it into the actual UI, as I need to rework some parts there to get everything to fit, ie. I'll probably have to break it into separate views for it to work on such a small screen and provide buttons or menus for moving between them. Once I get around to that, I'll also build the settings-saving, so it'll remember the warning-levels after restarts.

Edited September 12, 2015 by esaj

[esaj]

Getting there... Screenshot from actual phone, so small screen to fit everything into it  . Not sure why the buttons go partially outside the screen (yet another case where the UI-designer in Android Studio doesn't show it as it's seen on a real device ). Record-button isn't wired yet to anything & I have to check that the recording also works in background (so your data capture isn't cut because of incoming call etc), but other than that, getting ready for test run:

The "Speed Warning" -button shows/hides the speed warning settings, "Graph view" shows/hides the graph view seen above (I probably should just put one button there that toggles between the warning/graph -views), and Record will record, after I wire it in place... Also, the gray bar seen near the bottom is actually a text-input -field, and the lighter gray bar next to it is the "send"-button used to send commands to the wheel... Still cannot fit

Warning settings, the values are stored everytime they're changed & loaded on application start up, so it remembers the settings. "Enable warnings"-checkbox doesn't do anything yet, the warnings are always enabled  

[Tilmann]

Getting there... Screenshot from actual phone, so small screen to fit everything into it  . Not sure why the buttons go partially outside the screen (yet another case where the UI-designer in Android Studio doesn't show it as it's seen on a real device ). Record-button isn't wired yet to anything & I have to check that the recording also works in background (so your data capture isn't cut because of incoming call etc), but other than that, getting ready for test run:

Great stuff! Your first prototype kept on recording happily in the background, btw.

Happy to test the new app tomorrow if you want me to. I often fail to recognize the vibration alarm from the phone itself, so I was happy to find out, that my Pebble vibrates when my phone does. It would be interesting to find out, whether it does that with alarms coming from your app, too...

[esaj]

Of course I hit a couple of more problems when testing with vee's phone (things happen a bit differently in different Android-versions, like the directory structure, the phone didn't have the default documents-directory at all, which crashed nicely on recording ), but managed to sort them. Also it looks like the connection attempt fails a lot more on the phone than on the tablet, tried adding some delays there, but didn't seem to matter much (some threads about the subject suggested waiting a bit between canceling device scan and connection). After it opens, it seems to work flawlessly though.

By the time I was ready to go out and test, of couse clock just hit 4AM and the streetlights went out (during the week they go out at 12AM). Well, I just taped a small flashlight on vee's GW and set out. I again shot a video while riding (not that easy holding two phones in your hands, trying to see where you're going and what you're shooting ). Also recorded the data with the app.

The first part is going up the street (slight incline), and then down the hill where my Firewheel shutdown on Monday, I kept my speed low (15 km/h'sh) as I couldn't see that well all the bumps and didn't want to risk breaking either phone (I don't own either of them ). I was having hard time getting the axes to line up in the graph without excessive empty space, but I hope you can get something out of it (click for larger version):

Left axis is speed/power/voltage/current (all in single units), right axis is power. The power goes up a lot more at start to get moving, then you can see me going up the street, and after turning to the downhill, mostly just regenerative braking. After getting all the way to down, I stop the wheel (not even braking strongly) causing a -1.25kW regenerative spike.

After getting down the hill, I stopped and made another recording riding up and then down the slight decline towards my house. I made a couple of circles at the end and then stopped to front of the house.

Going uphill needs some power, some voltage sag there, but nothing major. The regenerative spike towards the end is me braking in front of the house, similar to the one when I got downhill. These really are not strong braking yet, although they cause over 1kW spikes. Then I rode the circles (the spot where I rode them inclines sideways a bit, so you can see I rode three circles before stopping) and came to a stop in front of the house.

Here are the video clips from from, first going up the street and then downhill, then after : , coming back uphill, down the street and the three circles, though there's nothing much to see really (I'm just shooting the phone running the app):

 

The graph is first showing voltage, until around 0:27 I change it to show current. Coming back (1:37 forwards) I had set it to show the power before starting to shoot. The vibration alerts also seemed to work nicely, although I still need to set that they can be changed correctly (ie. that the service reacts to changes in UI immediately), have to try and do some more testing tomorrow (and record data from some really heavy uphill riding in the hiking paths).

[Tilmann]

Yeah, night time sleep is completely overrated and just an irresponsible waste of time!   I'll keep screening the tabloids for alien sightings in Finland...

That's great data you're recording and I appreciate your effort to visualize it in this nice format. What comes as a surprise to me, is the relatively steady Voltage line. I expected to see a very noticeable increase by several volt at regenerative breaking. In your graphs, I can just see a hint of a Voltage increase from that breaking at 440 in your second run, but none at 532 in the first recording. It almost looks like there is an upper ceiling for the Voltage at about 63V. 

[esaj]

Yeah, night time sleep is completely overrated and just an irresponsible waste of time!   I'll keep screening the tabloids for alien sightings in Finland...

Next step is polyphase-sleeping, imagine all the extra time I had if I could get away with around 2-4 hours of sleep per day...

That's great data you're recording and I appreciate your effort to visualize it in this nice format. What comes as a surprise to me, is the relatively steady Voltage line. I expected to see a very noticeable increase by several volt at regenerative breaking. In your graphs, I can just see a hint of a Voltage increase from that breaking at 440 in your second run, but none at 532 in the first recording. It almost looks like there is an upper ceiling for the Voltage at about 63V. 

These weren't really strong braking, I've seen the voltage jump up 2-3V on strong braking with the Firewheel, which unfortunately means I cannot charge it very high for it to be safe to ride (around 60V rest-voltage seems "safeish"). I've also got the 4th battery pack since friday evening, but haven't yet torn down the wheel to add it (or even soldered the connectors to it), will have to see when I have the time...

[Jason McNeil]

Does polyphase sleeping actually work? I'm one of those where without my 8hrs & I'm not very much good for anything  Sleep deprivation tolerance seems to be largely genetic. http://www.journalsleep.org/ViewAbstract.aspx?pid=29575

Nice progress on the App. Do you know what the data acquisition rate is from the control-board? How can I get a 'beta' copy to compare with the in-line eLogger?

 

[esaj]

Does polyphase sleeping actually work? I'm one of those where without my 8hrs & I'm not very much good for anything  Sleep deprivation tolerance seems to be largely genetic. http://www.journalsleep.org/ViewAbstract.aspx?pid=29575

From what I've read, at least for some time yes, but getting used to it is a pain (it takes long before your REM-patterns adjust so that you fall into deep sleep immediately). The basic idea is that out of that "normal" around 8 hours of sleep, you're only in REM-state for about 2 hours. If you can get into REM-state immediately after falling asleep, you can take "fast REM-naps" throughout the day, the "uberman"-method is 20 minutes six times a day (so every 4 hours). People who have succeeded in it have also reported that after adjusting they automatically wake up after the around 20 minute period, no alarms needed.  https://en.wikipedia.org/wiki/Polyphasic_sleep

Nice progress on the App. Do you know what the data acquisition rate is from the control-board? How can I get a 'beta' copy to compare with the in-line eLogger?

I'll try to get a version out today or tomorrow, my in-laws (well, technically "in-law candidates", since we've been together for around 13 years, but never got married ) are visiting, so I can't really work on it right now. I have a few tweaks and a bit of testing to do before putting it "out in the wild".

EDIT: No idea on the rates, maybe 5-10 times per seconds... I'll put some millisecond-timestamps on the logged data to get a better picture, but as the processing of each message also takes some time (and there could be delays like Bluetooth re-transmits on broken packets), so it's not going to be 100% accurate.

 

Edited September 13, 2015 by esaj