[time-nuts] FS: More stuff
Two more items to get rid of. HP 8590A SA. 10 KHz to 1.5 GHz, -115 dBm to +30 dBm. Very clean. The screen has no burn-in and is very bright. It has the tilt handle, but no front cover. Option 21 (GPIB) is installed. HP 54522A scope. 2 GS/s, 500 MHz dual channel. Channel 2 has a bad input attenuator (I swaped attenuators to make sure). Very clean. The screen has no burn-in and is very bright. Missing one of the rear feet. Has serial, parallel and GPIB ports Make me an offer. Shipping will be extra. Joe Gray W5JG ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Fluke 6061A Synth. RF Generator
Hi All -- Sorry if this is off-topic, but you all have a lot of experience with equipment. I just picked up a 6061A and I'm happy to say it mostly works. But... at frequencies below 250 MHz, as the frequency output is decreased, the level drops too, and starting from +12dBm (rated out, more-or-less), by 20MHz, the positive peak of the sine wave is flattening -- this progression of level drop and increasing distortion keeps on until the bottom at 10kHz, where the level is over 4dB low and distortion is fairly significant. I'm a complete novice to this instrument and to synthesizers in general. I can use some tips about what circuits or parts might be causing this, or where to look to start on a fix. I do have a manual with schematics. I seem to recal reading that there is a Low Band circuit that works at 245MHz and below, so it seems like that may be where to start looking. Any and all suggestions appreciated. I welcome off-list comments if that seems most appropriate. Dick Moore ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Ublox 7
On Sun, May 25, 2014 at 1:26 AM, David J Taylor david-tay...@blueyonder.co.uk wrote: You can also get the u-blox 7 without the antenna - for example this pre-built unit for the Raspberry Pi, which has an SMA socket: I suspect that even if the target system is a Raspberry PI the critical point is the $17 price (including shipping). ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Ublox 7
From: Paul I suspect that even if the target system is a Raspberry PI the critical point is the $17 price (including shipping). For precise time frequency, I am surprised that cost is the first consideration, unless you are buying more than a few units! Especially if you weigh the effort required to remove the unwanted antenna. Oh, well! David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] GPS week number rollover finally bites Garmin GPS 45XL
A few days ago, I took my collection of obsolete handheld GPS receivers outside and turned them on, to let them find themselves and collect new almanac data. Most of them probably hadn't been turned on for 2 years or more. All of them eventually acquired satellites and started navigating. The old single-channel 45XL took 30+ minutes for this, the little Sony GPS-CS1 position logger needed only 30 seconds, and the others (all Garmin 12-channel handhelds) took perhaps 5 minutes. Once navigating, almost all of the units agreed that the date was May 22, 2014. All except the 45XL, which insisted on a date of October 6, 1994. Yes, exactly 1024 weeks early. I bought the 45XL in 1996, my second GPS receiver. It survived the actual week number rollover in 1999 (with a correctable problem; see below), and continued to work (as well as a single-channel receiver ever works) for many years afterward. Thus, the firmware was clever enough to know that low week numbers actually dates after mid-1999, not in early 1980. It probably did this with a birth week embedded in the firmware somewhere. But the birth week appears to be 1994 or earlier, since the 45XL looks at the current GPS week and concludes that today is in 1994, not 2014. I doubt if there is anything to be done about this, since the 45XL predates the Garmin units with firmware in flash. I think the 12XL was the first unit that could be updated by the factory, and user-updatable units came later yet. It remains to be seen what the other Garmin units (II+, eMap, eTrex) will do as they get near 20 years old; I wouldn't be suprised to see them start reporting incorrect dates as well. They do have flashable firmware, but I don't really expect Garmin to release firmware updates for 20 year old units. - Dave About the 45 XL in 1999: At the actual time of the WNRO in August 1999, the 45XL was operating in my car while driving on a highway, logging the trip. Nothing happened at 00:00 UTC that I noticed. I turned the 45XL off at about 00:30 UTC (17;30 local time) when we stopped for dinner. On return to the car, the 45XL would not acquire satellites, and we went without it for the rest of the trip. Within a few days, Garmin released a fix - a PC program that apparently used an undocumented interface command to clear the old almanac. (I guess the firmware did not handle week number rollover in the almanac correctly). But with the old almanac cleared, the 45XL did a cold start, resumed navigating, and continued working for another decade or more. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] SSR-6Tr vs Lotus M12M
Does anyone have experience with the Synergy SSR-6Tr and the fairly recent Lotus based M12M. It sounds like both are plug and play replacements for the Older M12M's. Both claim improved specs. Both my XLI and FEI Zyfer time and freq rec's use versions of the M12. Does anyone want to weigh in on which offers superior performance? Thanks and happy Memorial Day! Thomas Knox ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Weather/units question for European members
On May 23, 2014, at 11:12 PM, Mark Sims hol...@hotmail.com wrote: The nice thing about measuring temperature via sonic measurements is that the measurements are unaffected by solar heating of the apparatus... it does not need to be in the shade. I stumbled on this paper a while back when I was investigating a similar idea: Wen-Yuan Tsai et al, An ultrasonic air temperature measurement system with self-correction function for humidity, 2005 Meas. Sci. Technol. 16 548 http://iopscience.iop.org/0957-0233/16/2/030 It uses both time of flight and phase measurements. Since this is for rocketry, note that RockSim (a commercial package for simulating the trajectory of a model rocket flight) lets you choose a variety of units for windspeed and barometric pressure. I've used meters per second and hectoPascals with the kids I mentor on rocketry. One funny thing about weather measurements is that the data that NOAA reports is not what it would seem. The standard ASOS data (which is what NOAA reports in its local current conditions) includes barometric pressure in inches of mercury and in hectoPascals. It turns out that neither is the actual barometric pressure. First, both are compensated to sea level, so they are not reporting the station pressure. Next, the in.Hg measurement is actually altimeter setting, which is the value which, if set in the Kollsman window of a standard aviation mechanical altimeter located at the ASOS site, will cause the altimeter to indicate the height above sea level of the ASOS site. So it's really not related to sea-level barometric pressure in any direct way; it's not compensated for temperature nor for humidity, etc. It's just based on the standard atmospheric model as used by the standard aviation altimeter. There is a straightforward way to derive station pressure from the altimeter setting, so it's not entirely useless if you are not an aviator. Finally, if you try to compare the reported in.Hg barometric pressure versus the reported hPa barometric pressure, you will often find that the two values are not related by the standard conversion factor from in.Hg to hPa. That is because the ASOS hPa value is actually the average of the current station pressure, corrected to sea level (I don't know what factors are included in that correction), and the sea level corrected station pressure from 12 hours previous. This averaging is to correct for the diurnal variation in station pressure resulting from solar heating. Without this correction, the weather fronts would oscillate back and forth on the weather map with a 24 hour period. So unless you are drawing weather maps, the ASOS hPa value is useless. So, when RockSim asks the user to input barometric pressure, exactly which one does it mean? Note that it also asks for the height above sea level of the launch site. Does it take altimeter setting and assume that it is measured at the height above sea level of the launch site, derive the station pressure from that, and then apply a temperature and humidity compensated version of the standard atmospheric model to calculate the air density profile for the simulated rocket flight? What if the station height above sea level isn't the same as the launch site above sea level? Does it even take any of these complications into account, and just assume that the number you enter for barometric pressure is the station pressure at the launch site? If so, note that most folks just enter the barometric pressure number reported by the local weather forecast. This is one of the dangers of relying on closed-source programs for science and engineering; you can't tell what it's really calculating. It seems like what is the barometric pressure should be a simple question, but it turns out to be quite subtle. Best regards, -Steve -- Steve Byan steveb...@me.com Littleton, MA 01460 -- Steve Byan steveb...@me.com Littleton, MA 01460 ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] SSR-6Tr vs Lotus M12M
Hi Newer is always better :)…. The real question is : Did the guys who designed the the hardware and firmware in a 10, 20 or 30 year old box optimize it so that a better GPS would improve the performance of the box? Put another way: 1) Will the software filters tune in a fashion that allows better performance in less time? 2) Are the hardware TDC’s high enough resolution to keep up with the new GPS? That assumes that the M12M Lotus 100% matches the part in your older boxes as far as commands and i/o strings. Someone designing a box for selective availability conditions would have a much different task that a modern designer. It’s reasonable to guess that they could come up with a very different solution to the problem. Bob On May 25, 2014, at 3:10 PM, Tom Knox act...@hotmail.com wrote: Does anyone have experience with the Synergy SSR-6Tr and the fairly recent Lotus based M12M. It sounds like both are plug and play replacements for the Older M12M's. Both claim improved specs. Both my XLI and FEI Zyfer time and freq rec's use versions of the M12. Does anyone want to weigh in on which offers superior performance? Thanks and happy Memorial Day! Thomas Knox ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Weather/units question for European members
I ran across this very issue when trying to calibrate my barometer chip against the NWS station located less than two miles away. Their numbers for millibars and inches of mercury do not agree. I sent them an email and asked what was going on. They said their instruments read out in millibars (to three decimal places) The reported value is converted to sea level pressure and reported to two decimal places. They are also converted to inches of mercury for their reports. Only problem is their conversion constant is NOT the proper value. They consistently report around 0.02 too high. I reported this back to them, but have received no further responses. Note that the conversion between true pressure readings and sea level pressure involves an equation with about a fifth power/root (depending upon the direction of the conversion) so it can be quite sensitive to true chip calibration. The pressure chip that I am using (MP5611) is factory calibrated and has calibration constants stored on-chip (the Bosch BMP085 and BMP180 chips also do this), but the soldering process can affect the chip so you need to do some final calibration. The MP5611 can detect the air pressure change seen by raising the chip less than 6 inches... Relevance of temperature/humidity/pressure sensors to time-nuttery? We all know the comparatively massive effects of temperature on our equipment. But humidity and air pressure also affect them in many subtle and not-so-subtle ways. I'll post some recommendations/observations on various sensor chips in a while. - One funny thing about weather measurements is that the data that NOAA reports is not what it would seem. The standard ASOS data (which is what NOAA reports in its local current conditions) includes barometric pressure in inches of mercury and in hectoPascals. It turns out that neither is the actual barometric pressure. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Weather/units question for European members
atmospheric pressure taken for a weather observation is measured in millibars and respresents the barometric pressure at ground level at that location. If the instrument is located somewhere besides ground level it will be corrected to ground level. The value given in inches of mercury is that barometric pressure corrected to sea level and converted to inches of mercury. This is the altimeter setting and will be used by aircraft to adjust their altimeter so that when on the ground the altimeter will read the height of the aircraft above sea level, in other words the ground elevation on which the aircraft is sitting. This means there is no direct comparison between the pressure given in millibars and that given in inches of mercury (altimeter setting) unless the altimeter setting is corrected to the same height above sea level at which the atmospheric pressure was measured. The Altimeter setting in Europe is not the same. There the altimeter setting is such that the aircraft's altimeter reads ZERO when on the ground. Two miles away is pretty close but can make a difference as can a difference in ground elevation but it sounds like you are taking ground elevation into account already. cheers, Graham ve3gtc On 2014-05-25 23:06, Mark Sims wrote: I ran across this very issue when trying to calibrate my barometer chip against the NWS station located less than two miles away. Their numbers for millibars and inches of mercury do not agree. I sent them an email and asked what was going on. They said their instruments read out in millibars (to three decimal places) The reported value is converted to sea level pressure and reported to two decimal places. They are also converted to inches of mercury for their reports. Only problem is their conversion constant is NOT the proper value. They consistently report around 0.02 too high. I reported this back to them, but have received no further responses. Note that the conversion between true pressure readings and sea level pressure involves an equation with about a fifth power/root (depending upon the direction of the conversion) so it can be quite sensitive to true chip calibration. The pressure chip that I am using (MP5611) is factory calibrated and has calibration constants stored on-chip (the Bosch BMP085 and BMP180 chips also do this), but the soldering process can affect the chip so you need to do some final calibration. The MP5611 can detect the air pressure change seen by raising the chip less than 6 inches... Relevance of temperature/humidity/pressure sensors to time-nuttery? We all know the comparatively massive effects of temperature on our equipment. But humidity and air pressure also affect them in many subtle and not-so-subtle ways. I'll post some recommendations/observations on various sensor chips in a while. - One funny thing about weather measurements is that the data that NOAA reports is not what it would seem. The standard ASOS data (which is what NOAA reports in its local current conditions) includes barometric pressure in inches of mercury and in hectoPascals. It turns out that neither is the actual barometric pressure. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
