sfsdf
The code worked differently when the moon was full
151–160 of 175 posts
Re: The code worked differently when the moon was full
#152Earlier quoted context omitted.
Our garage door opener has this problem. At very specific times of the year the sun confuses the infrared blockage sensor. The cause occurred to me when I lined up my eye to see what the sensor was seeing when it was failing, and I noticed the morning sun right next to the other end of the sensor stream. I moved a trash can to shade the sensor and it worked fine.
On sunny days our garage door won’t open until the remote is very close. Either the solar panels or inverter generate enough noise to interfere with the signal. A few months ago our garage door openers started working like normal again. That was great until we realized it was because the inverter had failed. When the inverter was replaced, our door problems started again.
Damn thats one electrically noisy inverter. I wonder how it passed EMC testing in the first place.
Re: The code worked differently when the moon was full
#153I heard a great story a while back for a digitization project where historic content was being provided by many libraries around the world, including one in Russia. The quality of the scanned books was excellent, except for a weird distortion every so often where part of the page would be shifted partway through as if someone had shifted half the page in Photoshop. This was only noticed in books over a certain size s…
This is why you see sensitive imaging equipment in labs on air tables. Sometimes the entire room is an air table.
Indeed — they're not cheap but if you need that, it's worth the cost. In this case you could probably avoid it simply by having the robot rescan the page if it detected a vibration but the research labs I used to support had experiments where that would have jeopardized months worth of work.
Re: The code worked differently when the moon was full
#154We once had a customer who would call us in a panic a couple of times a year saying our inspection equipment was experiencing unusually high false rejects and they were generating very high scrap rate. By the time we got a technician on site the next day, everything was working flawlessly and the customer couldn't reproduce the problem either. This went on for almost three years with various levels of escalation to t…
Our garage door opener has this problem. At very specific times of the year the sun confuses the infrared blockage sensor. The cause occurred to me when I lined up my eye to see what the sensor was seeing when it was failing, and I noticed the morning sun right next to the other end of the sensor stream. I moved a trash can to shade the sensor and it worked fine.
If I remember rightly, this incident was the motivating factor for adding "save failing images" capability to our software.
Re: The code worked differently when the moon was full
#155Is there a database or "online myth/story" archive of wacky bugs like this and in the comments? These would make for great "cocoa at night" reading!
[deleted]
Re: The code worked differently when the moon was full
#156Is there a database or "online myth/story" archive of wacky bugs like this and in the comments? These would make for great "cocoa at night" reading!
I enjoyed the collection at: https://news.ycombinator.com/item?id=23005140
Re: The code worked differently when the moon was full
#157> Not strictly the cycle of the moon but close. Meh. Just the old 49.7 days cycle that it takes to overflow 32 bits when measuring miliseconds. I was hoping for a "it works when I buy vanilla icecream and doesn't when I buy other flavour".
Yes and:
> Just the old 49.7 days cycle...
I've encountered datetime bugs and learned to take preventative measures.
I generally add a virtual clock shim to my projects, eg wrapping System.currentTimeMillis() or equiv.
Then I write unit tests for anticipated edge cases. Like midnight, end/start of year, etc. To ensure reporting, rollups, logging, grooming, etc. are working correctly.
Also allows me simulate elapsed time, so I verify out of order event processing and so forth.
Re: The code worked differently when the moon was full
#158I love/hate such bugs. Often hard to debug, but totally great to finally find the root cuase and a solution. I've once got a ticket stating "this script always crashes before 10 a.m." [1]
Re: The code worked differently when the moon was full
#159Earlier quoted context omitted.
in modern point to microwave systems, unless the budget is really high, or the path is very long, it's rather unusual to have a vertical spatial diversity setup. much of the problem of losing link due to fade is accommodated by modern radios that have advanced variable modulation and FEC, which can operate anywhere between 4096QAM 5/6 and QPSK 1/2.
Interesting, thanks. My information is dated, but also it was a project with some specific requirements. It's possible that our client opted for the vertical spatial diversity setup because of that. I'd be interested to know what you think is a very long link ... 10km? 100km? I can't say too much more about where we were.
Beyond 35-40 km is where you would start to see atmospheric ducting, temperature inversions and such really affect a link. In the bands where it pretty much has to be 6 GHz because anything 11 GHz or above (in the FCC licensed bands) would suffer extreme rain fade with the rain rate and amount of rain in the total length of the path.
Generally things where you'd be looking at a pair of 6 ft high performance dual polarity dishes at minimum, and ideally a pair of 8 ft. The budget for just a couple of those and getting them properly mounted and aligned is a lot already before adding a spatial diversity second dish at each end.
Re: The code worked differently when the moon was full
#160Earlier quoted context omitted.
Interesting, thanks. My information is dated, but also it was a project with some specific requirements. It's possible that our client opted for the vertical spatial diversity setup because of that. I'd be interested to know what you think is a very long link ... 10km? 100km? I can't say too much more about where we were.
Beyond 35-40 km is where you would start to see atmospheric ducting, temperature inversions and such really affect a link. In the bands where it pretty much has to be 6 GHz because anything 11 GHz or above (in the FCC licensed bands) would suffer extreme rain fade with the rain rate and amount of rain in the total length of the path. Generally things where you'd be looking at a pair of 6 ft high performance dual pola…
We were mostly dealing with 5km to 10km links, and it was some time ago. There were other considerations as well, so I didn't get into it too much ... not my field, the peeps doing the work seemed to know what they were doing (both customer and supplier), and I had other things to worry about. Extreme real-time data compression is interesting when you're on a lossy link.
I don't think budget was a problem for this customer, getting it right was important, but useful to know about the options and constraints ... thank you.