Just a comment on real-time programming. Obviously the accuracy of the real-time performance is a function of the hardware/software system's clock speed -- if you have an attoHz-class microprocessor (MCU), most things are going to look real-time to most people (except time nuts, of course :-) ) no matter how they are coded ...
In the real world, where clocks are usually in the MHz range, you can achieve the real-time performances of your hardware (say, of a 32-bit output compare timer peripheral or a 12-bit DAC) as long as the overlaid software does not interfere with the peripheral's proper functioning. With a "set-and-forget" peripheral that is easy. With one that e.g. needs to be "fed" by the overlaid software (say, a DAC that is fed by DMA from data coming from outside), that is a bit more difficult. And if some of that real-time performance needs to happen in a task, then you really need a couple of software architectural features to get you there. As an example, an MCU-based system that uses queues to manage priority is not going to achieve real-time task performance, because e.g. the time to enqueue a task will not be constant-time, and it will thereby introduce timing jitter into the execution of all tasks. If, OTOH, in this example the queuing mechanism were implemented via a hardware timer and ISR that handles queueing via a an array (so that the queuing algorithm is constant-time), AND that ISR is elevated to the highest priority, then the task jitter in that system will be rather minimal, subject only to time deltas due to the system serving any other interrupts (regardless of interrupt preemption, etc). I.e. if the MCU is serving say a UART interrupt when the "main" timing interrupt occurs, either the system has to (HW) context-switch out of the UART interrupt to go service the timer ISR (and (SW) context-switch), OR it has to wait for the UART ISR to end, before servicing the timer interrupt. In the former, jitter will be a function of the MCU's interrupt handling; in the latter, it'll be a function of your code. While hardware preemption is always your friend, software preemption (in the general case) is not a panacea. For example, in a preemptive RTOS, every context switch is going to involve an interrupt. That "extra" interrupt will affect the responsiveness and jitter of your other interrupts. A cooperative RTOS does not involve any interrupts when context-switching, and so (from one of several perspectives), a cooperative RTOS (that in theory is not as responsive as a preemptive one) may in fact yield certain better real-time performances than a preemptive RTOS. So, bottom-line rule of thumb: if you want to get minimal timing jitter out of an MCU application, it is possible to run an RTOS (of any sort, most are soft real-time, very very few are hard real-time) on that MCU, and with careful attention to how you architect the system split between hardware peripherals and firmware on the MCU, you can get to the exact hardware timing specifications of the MCU itself. IMO the use of an RTOS makes a ton of sense here, because you can e.g. implement a complete GUI, comms system, terminal or other as part of the MCU application, safe in the knowledge that all this "RTOS overhead" has _zero_ impact on the real-time performance you hoped to get out of the MCU. This does require careful coding in certain areas ... I am a huge proponent of loosely-coupled, priority-based, event-driven MCU programming. Assuming it's coded well, it is not incompatible with nearly-real-time programming. For high-performance MCU programming, I generally follow these rules: - For 1-to-100-instruction-cycle timing accuracy, use straight-line (uninterrupted) instructions (Assembly, or C if your compiler is good) while interrupts are disabled. Here, your jitter is your fundamental clock jitter as it passes through the MCU. - For 100-to-1000-instruction-cycle timing accuracy, code it using an interrupt. Here, your jitter is dependent on the interrupt handling of the MCU. - For greater than 1000-instruction-cycle timing accuracy, hand it over to the (properly configured) RTOS. Here, your jitter is dependent on how the foreground (interrupt-level) vs. background (task-level) code operates in your application. --Andrew -------------------------------- Andrew E. Kalman, Ph.D. On Sun, Apr 25, 2021 at 7:14 AM Lux, Jim <[email protected]> wrote: > On 4/25/21 6:40 AM, Bob kb8tq wrote: > > Hi > > > > > >> On Apr 25, 2021, at 9:31 AM, Lux, Jim <[email protected]> wrote: > >> > >> On 4/25/21 6:02 AM, Bob kb8tq wrote: > >>> Hi > >>> > >>> The thing that I find useful about a GPS simulator is it’s ability to > calibrate the > >>> time delay through a GPS based system. In the case of a GPSDO, there > may be > >>> things beyond the simple receiver delay that get into the mix. Getting > the entire > >>> offset “picture” all at once is nice thing. Yes, that’s a Time Nutty > way to look at it….. > >>> > >>> So far, I have not seen anybody extending this sort of calibration to > the low cost > >>> SDR based devices. Without digging into the specific device, I’m not > sure how > >>> well a “generic” calibration would do. Indeed, it might work quite > well. Without > >>> actually doing it … no way to tell. > >>> > >>> So if anybody knows of the results of such an effort, I suspect it > would be of > >>> interest to folks here on the list. > >>> > >>> Bob > >> > >> A double difference kind of relative measurement might be useful - > compare two (or three) GNSS receivers. Then the absolute timing of the > test source isn't as important. > > Well …. it is and it isn’t. If you are trying to get “UTC in the > basement” (or even > > GPS time) to a couple nanoseconds, then you do need to know absolute > delays > > of a number of things. Is this a bit crazy? Of course it is :) > > > > Bob > > > Good point.. > > For many SDRs, it's tricky to get the output synchronized to anything - > a lot were designed as an RF ADC/DAC for software SDR (like gnuradio). > The software SDRs are sort of a pipeline of software, with not much > attention to absolute timing, just that the samples come out in the same > order and rate as samples go in, but with a non-deterministic delay. > Partly a side effect of using things like USB or IP sockets as an > interface. And, to a certain extent, running under a non-real time OS > (where real time determinism is "difficult programming" - although > clearly doable, since playing back a movie requires synchronizing the > audio and video streams ). > > If your goal is "write software 802.11" you don't need good timing - the > protocol is half duplex in any case, and a millisecond here or there > makes no difference. > > A SDR that has a FPGA component to drive the DACs might work pretty > well, if you can figure a way to get a sync signal into it. One tricky > thing is getting the chips lined up with the carrier - most inexpensive > SDRs use some sort of upconverter from baseband I/Q, and even if the I/Q > runs off the same clock as the PLL generating the carrier, getting it > synced is hard. > > The best bet might be a "clock the bits out and pick an appropriate > harmonic with a bandpass filter". If the FPGA clock is running at a > suitable multiple of 1.023 MHz, maybe this would work? Some JPL > receivers use 38.656 MHz as a sample rate, which puts the GPS signal at > something like 3/4 of the sample rate. > I'd have to work it backwards and see if you could generate a harmonic > that's at 1575... > > > _______________________________________________ > time-nuts mailing list -- [email protected] -- To unsubscribe send > an email to [email protected] > To unsubscribe, go to and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] -- To unsubscribe send an email to [email protected] To unsubscribe, go to and follow the instructions there.
