I've got the same issue - I asked about it a few weeks ago in this post. It's disappointing to hear that it's a hardware issue, as I'm really not inclined to buy another cable after the last one never worked. I'm considering writing some code to re-connect, as it does seem capable of recovering, but it would leave gaps in the data and would be a pain in general. All in all, I appreciate that Zeo has opened up the hardware and the API, but like you say, it's more hassle than it's worth. As it stands now, my Zeo isn't very useful, as most of my "awake" moments are recorded as "deep sleep" - I really wanted to be able to investigate the raw data and try to fix the problem.

I'm considering the Mobile version as well, though I'm a bit worried that I'd just be pouring money into a problem that doesn't seem to work in my new apartment. Zeo's definitely helped me focus on sleep over the past few months, I just wish I could get more realistic results! I wonder if I could trade in my Bedside for a Mobile...

By the way, there is a C API that was made by TJ on these forums: http://www.ecstaticlyrics.com/secret/zeo_raw_data_parser.tar.bz2 (not for Android though).

I just noticed that your code is written in C as well. Sorry, I got confused by your "C API would be cool" statement - I guess you meant for Android.

I think the best strain relief is none at all.

Most of the time when you're talking about strain relief, you're talking about connectors that connect firmly and securely in place (like the old screw-on serial port connectors) where you then decide you're going to pick up the device and move it around constantly, but you don't want the cable to get broken in half near the connector since that is where it undergoes the most strain.  Another good example is coaxial cable attached to a television.  That will come apart easily if you move the television around a lot.  However, you're also likely to bend the connector on the television, as it isn't designed to provide strain relief.

...and that's where I think your problem is.  The Zeo isn't designed to provide strain relief either.  That's just a header pin connector in there.  As you say, the connector doesn't even snap into place.  The hole wasn't designed for any connector (despite claims to the opposite, just take it apart and look at it, it's obviously just a hole).  Thus, to expect to build up a cable and connector with epoxy and have strain forces absorbed by the Zeo instead of the cable itself is only going to lead to a broken Zeo.  

The best place to focus your strain forces is into the wire itself.  It's the easiest component to replace.  Just strip of a little more insulation and attach a new connector.  If you buy solder-type header pin connectors instead of the crimp-on connectors, it'll cost you a dime every time you have to do it.  ...and if you do it right, you won't be doing it often.

Just strip off some of the outer black insulation from the FTDI cable.  (I just rely on what's already exposed, but if you ever have to repair it, you may need to strip some off.)  This way, all of the strain is easily delt with by the three thin flexible wires which go from the bulky black part of the FTDI cable to the header pin connector in the Zeo.  Now when you move the Zeo around, just those three little wires have to bend, and they bend rather easily, so it's no big deal.  I've been using my Zeo this way for seven months now and I've had no problems whatsoever.  The cable hasn't even accidentally come loose, though I make sure to check that it's still fully inserted every time I move the Zeo (which is rare so it's no big deal).

As for the Zeo having a USB connector, I agree it'd be nice, but I understand why it doesn't.  After moving to a new house two weeks ago, I've been living in an arrangement where my bed simply isn't anywhere near my computer.  So when I want to view my sleep data, I take the SD card out of the Zeo and load the data into my computer.  It's quite easy to do and is a very simple solution to recording data without having to sleep in the same room with a noisy computer turned on all night.  So I totally understand why it works that way.

I'd like to see the raw data written to the SD card as well.  (Also fix all the bugs, they're quite annoying, particularly the 16 hour limit on sleep length.)  Having the option for live data is nice, but for simply doing your own analysis on the waveform data, just reading it from the card in the morning is adequate, and that would make it rather easy for people to use the random applications people make.  I only wanted the live data initially so that it was easy to sync the Zeo's data with other data I collect, since sometimes I like to record respiration data and trying to sync it up with the Zeo data in the morning would be difficult.  It's much easier to just record both data streams simultaneously, then there's no question of how they sync together.

I am surprised that you're still working on that library.  I thought the piece of code I put together for you demonstrated quite nicely that the protocol, while more complicated than necessary, just isn't all that difficult to deal with.  Honestly, I don't see a need for a library at all, other than that Zeo hasn't provided much in the way of documentation.  For the live data I mostly went by the quick summary that is in one of the source files for the library, then referred to the code itself (though it is written in a language I don't understand) to figure out a few details.  For the SD card data, I just used the data dumping utility to find what data I was looking for, then looked at hex dumps of the binary data to figure out where it was stored.  That might take a while if I cared to find all of the data, but after finding the hypnogram data and the start times, I decided I didn't really care about any of the other data.  

I think everyone is focusing too much on the live data stream anyway.  For the most part, all I've used it for is to make up for the bug in the SD card data where, when the Zeo decides to join two sleep periods (you wake up for an hour, then go back to sleep) it fills in the gap in the hypnogram data with code 1 (awake) instead of code 0 (no data) which it should use since, as the headband wasn't in use, it doesn't really know that I was awake.  (plus I like to see "awake but trying to sleep" show up differently than "awake and not even in bed" in my reports)  Using the live data I can properly record that the headband wasn't in use at the time.  While I've been recording the raw data for months, the only portion I've been using is the sleep stage data, which I could just as easily read from the SD card were it not for that bug. 

So I've been making reports like these: 

http://www.ecstaticlyrics.com/secret/seven_months.pdf

Color codes:  black = REM, dark blue = deep, light blue = light, yellow = awake, white = not in bed / unknown.  At the end, you see the lack of yellow...  That's because I just discard the awake codes from the SD card since so many of them should actually be no data codes which are drawn in white. 

Using this, I've discovered a strange link between caffeine use and interruptions in my REM sleep.  Even small amounts of caffeine, like a can of soda in the morning, will affect my sleep that night, and larger amounts will affect the next night as well.  However, if I cease all consumption of caffeine, there's an improvement for a few days, then it goes back to how it was before.  So lately I've been eating a chocolate bar in the morning for the even smaller amount of caffeine it contains, to see if I can keep myself in that sweet spot where my REM sleep benefits.  So far it seems to be working, but it really needs a lot more study to reach a conclusion.  In particular, I'm always trying multiple things at once, so I need to see it work for like six months to really believe it.

It seems to me that anyone who wants to make a truly useful application should probably forget about the raw waveform data.  It's difficult to interpret, and so I haven't seen anyone try.  Instead they just display the wiggly lines as if that will do anything but amuse people.

I've thought about rewriting my PDF generating application so it's useable by other people.  It's a mess of Perl scripts and command line utilitys (and for Linux at that) at the moment, so I can't really offer it to the general public.  However, I'm generally too tired to do such complex things.  There's a reason it's such a crude hack: that's all the energy I had when I wrote it.

I think people could do a lot of good to write some applications that work on the raw waveform data.  One idea would be to have an application which you can program with any supplements you might be taking and their half-lives, so that you can tell the program when and how much you take, and it can calculate the exact amount in your bloodstream from moment to moment.  Then it can determine if the supplement is having any effect on your sleep, and also determine what the ideal amount is.  Thus, if I programmed it for caffeine, and told it every time I consumed some soda or chocolate or coffee, it'd be able to tell me that my ideal amount of caffeine is 5 mg or whatever it is.  (I'm still rather surprised that the ideal amount isn't zero.)  I've also been trying other supplements like Choline, which the body uses to make acetylcholine, which is the main neurotransmitter used for throat muscles I beleive, and so may help to keep my airway open.  However, both too much and too little acetylcholine will weaken the muscles, so it's definately the sort of thing where finding exactly the right dose would be necessary.

Personally, I'm just amused with the way my data is displayed in that PDF.  It's really far more workable than anything that attempts to display sleep as "nights" since my sleep is far too irregular for that.  So even if all your application offered was a different way to view the same data, it might just be exactly what some other people are looking for.  ...and if all you're doing is reading the SD card data, no one has to hack together a USB cable to use your application.  They can just run it on the data they already copy to their computer all the time anyway.  (Well, they still have to install the firmware update, I guess.)

I think the main advantage to the cable interface (with the same functionality provided by the Zeo mobile interface), is the real-time streaming. One thing I'd like to have it do is calculate ZQ on the fly so that I can glance at it and decide if I should suck it up and get up, or if I really do need the extra sleep. I'm terrible at assessing my sleep first thing in the morning - I've got some days that I gave a 1 for "morning feel" and then a 10 for "day feel", so if I could have some external guidance on that front I'd at least give it a shot.

Then there's the laziness aspect of not having to physically remove the card...

P.S. why is it that posts on this forum have to be queued for moderator approval and then take weeks to appear? I posted about this and other forum issues in the support forum, and then felt like an idiot when it posted immediately.