search

kriswiner / EM7180_SENtral_sensor_hub

(Affordable) Ultimate Sensor Fusion Solution
https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution/
96 stars 37 forks source link

Hub won't start #60

Open JNatael opened 4 years ago

JNatael commented 4 years ago

For some time now I've been having trouble with a sensor hub that previously worked. For some time the device worked fine. Then it got shipped internationally and on arrival, no longer worked. All the other devices work fine, but when attempting to start this one I get this problem: https://github.com/simondlevy/EM7180/issues/16.

I've found no way around this and can find no reason why the device would suddenly fail to respond. The best I can figure is maybe in transit the radiation exposure on the plane flipped a bit somewhere and the original firmware got corrupted (all the attached devices in the same circuit still worked fine on arrival so I can't figure anything else). This device was meant to be flexible though, right? So no problem, I'll reflash the firmware and should be good!

Ordered a Teensy, ordered a usb reader, soldered stuff, and sat down tonight to flash it only to discover this: https://github.com/kriswiner/EM7180_SENtral_sensor_hub/issues/18

The firmware software needed is no longer available.

So as it stands now I have a device that once worked great but seems, after a mere few months, to have become unusable.

Is there a way around this? Does anyone else see a solution? I was really happy with this product for the short time it worked, but if I don't find a way around this issue I have a very tiny and ineffective paperweight. Help!?

JNatael commented 4 years ago

A quick followup; the original code issue referenced is in a separate python driver rather than this repository, but the line that fails is attempting to set a parameter in this device (disabling Stillness mode) and the line just always fails. I've tried multiple versions of the driver all to no avail so the best I can figure is the device itself has stopped responding, which is what led me to think corruption of some sort. If that chain of evidence should lead somewhere else I'd love to know that too.

kriswiner commented 4 years ago

Always possible the EEPROM got chipped or damaged via handling, etc. No idea. These EEPROM are reasonably robust, and are shipped all over the world without such a mishap.

Only alternative is to buy another one, or find another equivalent sensor solution.

On Thu, Sep 12, 2019 at 4:06 PM JNatael notifications@github.com wrote:

For some time now I've been having trouble with a sensor hub that previously worked. For some time the device worked fine. Then it got shipped internationally and on arrival, no longer worked. All the other devices work fine, but when attempting to start this one I get this problem: simondlevy/EM7180#16 https://github.com/simondlevy/EM7180/issues/16.

I've found no way around this and can find no reason why the device would suddenly fail to respond. The best I can figure is maybe in transit the radiation exposure on the plane flipped a bit somewhere and the original firmware got corrupted (all the attached devices in the same circuit still worked fine on arrival so I can't figure anything else). This device was meant to be flexible though, right? So no problem, I'll reflash the firmware and should be good!

Ordered a Teensy, ordered a usb reader, soldered stuff, and sat down tonight to flash it only to discover this: #18 https://github.com/kriswiner/EM7180_SENtral_sensor_hub/issues/18

The firmware software needed is no longer available.

So as it stands now I have a device that once worked great but seems, after a mere few months, to have become unusable.

Is there a way around this? Does anyone else see a solution? I was really happy with this product for the short time it worked, but if I don't find a way around this issue I have a very tiny and ineffective paperweight. Help!?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/EM7180_SENtral_sensor_hub/issues/60?email_source=notifications&email_token=ABTDLKS2V5YJYOIUQRT5LKDQJLDOJA5CNFSM4IWKPMY2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HLDT6JQ, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTDLKWQ7EARVFRWKBJTI2TQJLDOJANCNFSM4IWKPMYQ .

kriswiner commented 4 years ago

Are you saying the boards runs fine except for this line???

Then there is nothing wrong with the firmware.

On Thu, Sep 12, 2019 at 4:12 PM Tlera Corporation tleracorp@gmail.com wrote:

Always possible the EEPROM got chipped or damaged via handling, etc. No idea. These EEPROM are reasonably robust, and are shipped all over the world without such a mishap.

Only alternative is to buy another one, or find another equivalent sensor solution.

On Thu, Sep 12, 2019 at 4:06 PM JNatael notifications@github.com wrote:

For some time now I've been having trouble with a sensor hub that previously worked. For some time the device worked fine. Then it got shipped internationally and on arrival, no longer worked. All the other devices work fine, but when attempting to start this one I get this problem: simondlevy/EM7180#16 https://github.com/simondlevy/EM7180/issues/16.

I've found no way around this and can find no reason why the device would suddenly fail to respond. The best I can figure is maybe in transit the radiation exposure on the plane flipped a bit somewhere and the original firmware got corrupted (all the attached devices in the same circuit still worked fine on arrival so I can't figure anything else). This device was meant to be flexible though, right? So no problem, I'll reflash the firmware and should be good!

Ordered a Teensy, ordered a usb reader, soldered stuff, and sat down tonight to flash it only to discover this: #18 https://github.com/kriswiner/EM7180_SENtral_sensor_hub/issues/18

The firmware software needed is no longer available.

So as it stands now I have a device that once worked great but seems, after a mere few months, to have become unusable.

Is there a way around this? Does anyone else see a solution? I was really happy with this product for the short time it worked, but if I don't find a way around this issue I have a very tiny and ineffective paperweight. Help!?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/EM7180_SENtral_sensor_hub/issues/60?email_source=notifications&email_token=ABTDLKS2V5YJYOIUQRT5LKDQJLDOJA5CNFSM4IWKPMY2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HLDT6JQ, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTDLKWQ7EARVFRWKBJTI2TQJLDOJANCNFSM4IWKPMYQ .

JNatael commented 4 years ago

Are you saying the boards runs fine except for this line??? Then there is nothing wrong with the firmware. On Thu, Sep 12, 2019 at 4:12 PM Tlera Corporation tleracorp@gmail.com wrote:

Well, I can't tell about runs fine, this is in the boot sequence of the board which effectively never finishes. So up until that line in the boot sequence yes it runs fine, but then at that line it now stops.

It was actually a small piece of a much larger project and fairly well packed in so I think damage is highly unlikely; far more sensitive and exposed components were fine. I'm aware my radiation theory is a bit of a conspiracy theory but I couldn't figure out any other potential explanation for why behavior manifested that had never before been an issue and corruption from such is a problem a few miles higher in space so I figured maybe it can occur at 30k feet too. More so because the line that stops is effectively trying to set a parameter on the hub and that's where it fails, leading me to think corruption.

JNatael commented 4 years ago

Always possible the EEPROM got chipped or damaged via handling, etc. No idea. These EEPROM are reasonably robust, and are shipped all over the world without such a mishap. Only alternative is to buy another one, or find another equivalent sensor solution.

Yeah, I've been pretty happy with it so far, figure it was just bad luck in the shipping. I'm doing this for something that may become a product though so I can't afford to have this kind of behavior for the final version; is there a way to know if this might happen again or a way to deal with it?

Alternatively, is there an equivalent sensor solution you can suggest?

kriswiner commented 4 years ago

This https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution-lsm6dsm-lis2md/, and this https://hackaday.io/project/160283-max32660-motion-co-processor which will be available soon.

On Thu, Sep 12, 2019 at 4:20 PM JNatael notifications@github.com wrote:

Always possible the EEPROM got chipped or damaged via handling, etc. No idea. These EEPROM are reasonably robust, and are shipped all over the world without such a mishap. Only alternative is to buy another one, or find another equivalent sensor solution.

Yeah, I've been pretty happy with it so far, figure it was just bad luck in the shipping. I'm doing this for something that may become a product though so I can't afford to have this kind of behavior for the final version; is there a way to know if this might happen again or a way to deal with it?

Alternatively, is there an equivalent sensor solution you can suggest?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/EM7180_SENtral_sensor_hub/issues/60?email_source=notifications&email_token=ABTDLKUHW4M5BEGZXWR63F3QJLFDDA5CNFSM4IWKPMY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6TRA7I#issuecomment-531042429, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTDLKRW2PDLBYQFIEBYBCDQJLFDDANCNFSM4IWKPMYQ .

JNatael commented 4 years ago

Thanks, those do look interesting! I don't immediately see drivers for the Pi though, am I missing them or I'd have to convert one to work myself?

Also, is there really no way to get a copy of the firmware file to try fixing the device I have? I checked and the ads/information for this device (both https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution-mpu9250/, for example, and the readme of this repo) still note the capacity to write the config file again. As a result it's a tad frustrating to have my device go effectively dead based on my inability to use a capacity that it was advertised with. Can the file not be hung at least somewhere for those of us who bought based in part on this advertising?

You've made a really great product here, and I was really loving using it; it would be such a shame to have it be effectively dead so soon after I got it.

And frankly, I'd love to be able to continue to work on my product instead of having to stop and make new Pi drivers for yet another device (yours was our fourth IMU, and it saved me a lot of time to require so little work to convert the drivers and get to good data).