Lack of Required IF Calibration

[K9EQ]

The AD7021 transceiver chip used in the Zumspot requires that the IF be calibrated. The IF is an analog on-chip system that is temperature sensitive and must be calibrated to perform well.

Analog Devices requires that an IF calibration be performed whenever the 7021 enters receive mode. In addition, if the 7021 spends a long time in Rx with no Tx, a calibration should be periodically performed. One reason for doing this is the temperature sensitivity. Ambient temperature changes as well as internal heat generated by transmitting on higher powers will cause the chip's temperature to drift.

This may seem nuts to most people reading this, but it is not unusual for these chip-based radios to require constant adjustment. This includes almost any lower power transceiver such as Bluetooth 4.0+.

It appears that the firmware only performs a calibration when switching modes. In addition it performs the calibrations in the wrong order. The firmware should perform a course calibration followed by a fine calibration. Since this is done in the wrong order it is almost guaranteed that the IF calibration will be wrong.

An improperly calibrated IF will lead to reduced receiver performance, possible increased sensitivity to frequency errors, and increased BER.

I suspect the DV4mini and OpenSpot have done this correctly and it is one of the reasons they do not have the extreme sensitivity to frequency error that Pistar-based hotspots have.

73,
Chris, K9EQ

[M1DNS]

The AD7021 transceiver chip used in the Zumspot requires that the IF be calibrated. The IF is an analog on-chip system that is temperature sensitive and must be calibrated to perform well.

Analog Devices requires that an IF calibration be performed whenever the 7021 enters receive mode. In addition, if the 7021 spends a long time in Rx with no Tx, a calibration should be periodically performed. One reason for doing this is the temperature sensitivity. Ambient temperature changes as well as internal heat generated by transmitting on higher powers will cause the chip's temperature to drift.

This may seem nuts to most people reading this, but it is not unusual for these chip-based radios to require constant adjustment. This includes almost any lower power transceiver such as Bluetooth 4.0+.

It appears that the firmware only performs a calibration when switching modes. In addition it performs the calibrations in the wrong order. The firmware should perform a course calibration followed by a fine calibration. Since this is done in the wrong order it is almost guaranteed that the IF calibration will be wrong.

An improperly calibrated IF will lead to reduced receiver performance, possible increased sensitivity to frequency errors, and increased BER.

I suspect the DV4mini and OpenSpot have done this correctly and it is one of the reasons they do not have the extreme sensitivity to frequency error that Pistar-based hotspots have.

73,
Chris, K9EQ

Chris.

The last few posts from yourself here seem to be all about the failings of the pi-star firmware.

You might not be aware but the firmware is not in the control of the pistar group. It is the work of the MMDVM dev. team
MMDVM host is the software at the heart of pistar, but software which isn't a product of the pistar team.

Pistar is the image which you install onto ur raspberry pi.
The user interface. Created to both allow users an easier path to getting their MMDVM installations up, configured and running, and giving users a control interface to drive their MMDVM host software / MMDVM hardware.
A wrapper for MMDVM, for want of a better explaination.


Although the team members here do support the work of the MMDVM (Dev) team in many differing ways, We (The pistar team) don't create the firmware used on MMDVM hardware, neither do we have control over how that firmware is written, or how its defined... that is the domain of the MMDVM team.

Now, my point... not looking to stem you from posting here on this particular group but as there is no instance where the pistar team has direct control over the firmware being made available, as written above.
I'd like to suggest you join either the MMDVM yahoo web group or the MMDVM FB group and posts your observations there. So directing ur observations to those that are immediately involved, and those that might give consideration to act apon the info you are providing.

Andrew M1DNS, (Mod)

[K9EQ]

Thank-you for taking the time to respond.

It is a bit confusing how all of this works and which bits are Pistar and so on. I looked through the Pistar website and couldn't find anything related to a development respository. So posted here.

Unfortunately most people will associate the Pistar brand with problems, even though those problems are caused by subsystems you don't maintain.

Does the Pistar team inject changes into the software repositories or is the effort limited to configuration and PHP code? If you're experience is anything like mine, with the YSF reflector software, software changes could make the PHP interface to it a lot easier and more consistent in its behavior.

73,
Chris, K9EQ

I'll poke around the MMDVM group.

[M1DNS]

MMDVM project...
https://github.com/g4klx


MMDVM HS firmware...
https://github.com/juribeparada/




Pistar...
https://github.com/AndyTaylorTweet

But as said pistar is an OS image, not a software package.

Andrew M1DNS, (Mod)