Implement internal temperature monitoring

[jboone]

No description provided.

[aernan]

Do I need to put a heatsink/fan on the HackRF or the Portapack chips?

[jboone]

No, this temperature monitoring is intended to automatically compensate for crystal reference frequency drift as the radio hardware warms up.

[aernan]

ok excellent. That’s a good heads up before I leave the unit on for any time.

On Aug 2, 2015, at 3:11 PM, Jared Boone notifications@github.com wrote:

No, this temperature monitoring is intended to automatically compensate for crystal reference frequency drift as the radio hardware warms up.

—
Reply to this email directly or view it on GitHub #8 (comment).

[jboone]

Temperature monitoring is now functioning. Will need further UI and supporting code to automatically adjust crystal reference frequency PPM offset based on current temperature.

Part of the problem is that temperature resolution is poor, so it's hard to interpolate values and make smooth PPM adjustments.

[KC5CQW]

Where is the sensor? No joy if it's inside the CPU and not near the LO.
It might be necessary to epoxy a thermistor to the xtal body and feed the leads into a pair of unused GPIO holes. One of the glass-bodied, high resolution types used in 3D printer hot ends would work well here. These are very well documented for linearizing the output of the thermistor within code for accuracy. Fine wire soldering and polymeric application will be required...

Additionally, if an external reference signal is applied, this temperature compensation MUST be ignored.

[jboone]

@KC5CQW The sensor is located in the MAX2837, the second IF chip. It's not an ideal location, but with the thermal mass of the circuit board, it seems to track OK. What doesn't work so well is that the MAX2837 temperature sensor has a resolution of 5C. This is barely enough to compensate for drift, so I'm unsure if it's actually worth completing the feature, or if I should just expect the user to manually calibrate PPM for when the unit is warmed up, which is what I'm doing now.

You're welcome to modify your hardware however you like. I fear almost nobody else will undertake such a modification. So I'm going to focus on doing it right in the next revision of the PortaPack. :-)

[KC5CQW]

Nah, i'm good. I built a GPSDO for the clock input when high precision is needed. From what I've seen, the screen resolution is too coarse to resolve such small deviation. A better option would be to manually adjust the PPM then activate an AFC algorithm to track the RX carrier to compensate for minor fluctuations.
A new revision?! Dang, this is going to get expensive... I have a hard enough time justifying my R/C helicopter habit to my wife.

[jboone]

@KC5CQW I definitely need AFC to improve sensitivity to signals transmitted significantly offset from my LO. This is particularly important for TPMS, where transmitters are very cheap and in an environment where temperatures vary widely, from -20C to 50C or more. But first thing's first.

And don't worry about a new revision. It'd be a whole new thing, and it's a long way off still -- I'd be amazed if I had anything together in a year.

[KC5CQW]

I have an idea... What about a simple, small thermal health status indicator using this "rough" data. Perhaps just one or two pixels in a corner that changes color. Blue for cold, green for room(ish) temp and red for way too hot. Maybe a hysteresis of 10's of degrees for averaging.

73, Damon

On Feb 3, 2016, at 12:20, Jared Boone notifications@github.com wrote:

@KC5CQW The sensor is located in the MAX2837, the second IF chip. It's not an ideal location, but with the thermal mass of the circuit board, it seems to track OK. What doesn't work so well is that the MAX2837 temperature sensor has a resolution of 5C. This is barely enough to compensate for drift, so I'm unsure if it's actually worth completing the feature, or if I should just expect the user to manually calibrate PPM for when the unit is warmed up, which is what I'm doing now.

You're welcome to modify your hardware however you like. I fear almost nobody else will undertake such a modification. So I'm going to focus on doing it right in the next revision of the PortaPack. :-)

—
Reply to this email directly or view it on GitHub.

[jboone]

@KC5CQW The thermal sensor is located in the second IF chip and is purely about calibration. The sensor is not positioned or designed for monitoring system faults or throttling, unlike laptop/desktop processors. Besides, if the HackRF + PortaPack experienced a fault that produced considerable excess heat, either the onboard switching regulator or the USB power source would enter current limiting.

In a different system design, having CPU core temperatures would be useful, as would a thermal sensor with much more accuracy, co-located with the reference crystal/oscillator. Or, dispense with the thermal sensor and use a more accurate (<1ppm) crystal to begin with...

[jboone]

After a few months of observation, I've concluded the temperature resolution of the MAX2837 is simply too coarse to implement automatic reference frequency compensation. Aggressive filtering of the coarse signal would still cause laggy and large swings in PPM offset, and would be worse than just leaving it manual. In practice, I find a PPM offset for each HackRF and leave it, as once a unit is warmed up (a few minutes), the PPM value is quite stable.

[sck-nogas]

I know that I can use the Receiver mode to help tune the PPM offset, but I have not been able to identify much/any drift using WFM. So, as my dumb question of the day, should we only use NFM or AM to tune this?

[jboone]

You won't see the offset in WFM mode, unless it's severe (and your HackRF crystal reference is way out of specification). Broadcast FM analog signals are ~260kHz wide, and the carrier is typically around 100 MHz. At 100 MHz, a 10 ppm offset would be 1 kHz, which would be very hard to see in the nearly 400 kHz WFM spectrum waterfall. A 1 kHz offset on such a wide signal is unlikely to affect demodulation significantly, so you wouldn't hear the effect, either.

NFM or AM is much better, as the signal and displayed bandwidth are far narrower, and it'll be easier to make fine adjustments. I usually adjust PPM whenever I see a need, and it's usually the same value, +/- 1 ppm, unless the transmitter I'm observing is very sloppy.

[KC5CQW]

Would it be possible to add a "relative" 0 setting to the PPM once a HRF has thermally stabilized and compared to a freq. standard? For example, at 25C, +/- ~30deg. my HRF is -7PPM. I would like to set this value as a relative "0" to monitor when a recalibration is necessary and to perform frequency measurements.
This is useful for when I am unable to sync with my 10MHz master clock back in the lab when going portable.
73, Damon

On Jul 28, 2016, at 10:59, Jared Boone notifications@github.com wrote:

After a few months of observation, I've concluded the temperature resolution of the MAX2837 is simply too coarse to implement automatic reference frequency compensation. Aggressive filtering of the coarse signal would still cause laggy and large swings in PPM offset, and would be worse than just leaving it manual. In practice, I find a PPM offset for each HackRF and leave it, as once a unit is warmed up (a few minutes), the PPM value is quite stable.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[KC5CQW]

Only an idle FM carrier will be on the target frequency. That means no modulation. CW is best then AM or LSB/USB for comparison.
Use of a NWS/NOAA broadcast in nFM is useful between modulated words.

73, Damon

On Jul 28, 2016, at 12:19, Scott C. Kennedy notifications@github.com wrote:

I know that I can use the Receiver mode to help tun the PPM offset, but I have not been able to identify much/any drift using WFM. So, as my dumb question of the day, should we only use NFM or AM to tune this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[sck-nogas]

Thanks!

Using NFM (after warming up for 10-15 mins of listening to the broadcast), I set my PPM to 11.

"Well, it's one louder, isn't it? It's not ten. You see, most blokes, you know, will be SDRing at ten. You're on ten here, all the way up, all the way up, all the way up, you're on ten on your HackRF. Where can you go from there? Where?... Eleven?" :)

http://www.imdb.com/title/tt0088258/quotes?item=qt0261726

[jboone]

@sck-nogas I appreciate starting my day with a little 'Tap. Thanks. :-)

I am curious to know if a PPM offset of +11 continues to work well for you, as it is a bit out of spec in my experience. What kind of transmission did you calibrate to? Depending, the transmitter may not be very precise...

[jboone]

@KC5CQW I like the idea... I've felt funny adjusting the PPM from within the receiver, like that's not really the place for it. However, I've also liked having that adjustment to fine-tune for a specific transmission.

So perhaps we rename the "PPM" inside the receiver mode to be "Fine", and if you press "select" on that value, you can update the global PPM value with the current "Fine" offset (and the Fine offset resets to 0). So perhaps we can have our cake (set PPM from receiver mode, where it's easiest), and eat it too (fine adjust the tuned frequency without messing up the global PPM value).

[sck-nogas]

@jboone You are MOST welcome. Am loving the Portapack!

For the tuning of the PPM, I followed @KC5CQW 's suggestion and used the two closest (both about 10 miles LOS) NWS NOAA stations KEC62 and WNG637 to my house. Then using the PPM adjuster in Receiver mode, I changed the setting until the red carrier line (observable when there was no audio transmitted) was centered.

I then jumped around to a few other NFM stations to make sure they all were equally centered on carrier.