Hacker News new | ask | show | jobs
by iasay 1431 days ago
Crazy shit like this happens all the time. However assigning a cause is a little early.

Years ago I wrote a firmware loader for an industrial Z80 system. All it did was read a file over the serial port into RAM, jump into it and then overwrite the EEPROM. I got a page quantity calculation completely wrong. It didn't update all the memory pages. Because the changes were fairly small and the code was assembled rather than compiled and the test cases were fairly light, it was released to clients. It still worked absolutely fine but the status LED didn't work on the device in a specific situation because the update CALL never got executed because it was neatly in a previous page that didn't exist any more.

Of course this was reported as (1) hardware had completely failed (2) the LED had broken and (3) it only works sometimes. All of which weren't true. No one had even mentioned that they had recently updated it. So I can see how it happens.

Thus the tyranny of unexpected behaviour is a deep and dark passage lined with monsters, misinformation and bad assumptions. You have to tread very carefully and not say things too soon because it makes you look even more of an idiot when you have to backtrack later.

1 comments

Crazy issues like that definitely do happen. But, this speaker output power issue being due to a file transfer error doesn't feel right. Do the perform any kind of integrity checking on the fw before installing it? Even an md5sum on the package seems like it would almost certainly have caught this. Either this wasn't caused by a file transfer problem, or their fw update process has some serious design issues.
Even easier than file integrity checks: testing the loudspeakers with various combinations of output level, musical material and battery states. They would have noticed.
A few notes regarding the latest firmware:

The sound profiles have not been changed at all. The playback time is exactly the same as before, i.e. 5 hours on max volume in Power mode. (confirming the SPL is the same) The settings for the woofers have not been changed at all. The contribution of tweeter sound pressure level is only a minor fraction of the total SPL for the speaker and since the woofers’ SPL has not been changed, the total SPL should stay the same as well.

As a result of the above, we have not seen any SPL change in our measurements post-upgrade, and are not sure as to why some users are experiencing this.

Previously, i mentioned the notion of it being a data corruption issue. We have integrity verification, so this is extremely unlikely, but as it is an easy check, we recommend trying this out. If you try to re-upgrade, and it skips the “transferring” step and goes directly to “Ready to patch”, it means that the previous upgrade had been successful with no corrupted data and that you have had the correct firmware on your speaker. (In this case it will be a very fast process) If however, it started to transfer files, it is worth to wait until the transfer step is completed to make sure you have the right firmware.

In the meantime, we will continue to investigate internally in SOUNDBOKS, and try to figure out why some users are experiencing this, when we are not experiencing it ourselves, and it has not occurred in any of our testing.

Again, thanks for your engagement!