Re: [time-nuts] 5370 firmware hacking status report
A quick check shows digikey sells them in single quantities, and has current stock. http://search.digikey.com/scripts/DkSearch/dksus.dll?Detailname=ADUM4160BRWZ-ND regards, Fred From: John Seamons j...@jks.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Sunday, July 24, 2011 11:05 PM Subject: Re: [time-nuts] 5370 firmware hacking status report On Jul 24, 2011, at 2:40 PM, Poul-Henning Kamp wrote: Ethernets big advantage is that it is galvanically isolated, USB is not. You had mentioned this issue in February. And since I currently flash using USB I went ahead and bought the evaluation card for the Analog Devices ADuM4160 power/signal isolator chip (see last pic on jks.com). Even though I programmed the GPIO pins on the micro for open drain I didn't know if the +5 on the USB from the host computer would fight the signals from the 5370. Plus I didn't want the ground loop. So the isolator chip splits the power domains and the micro is powered by +5 from the 5370. Works great. But I haven't found anyone who sells the chip in small quantities yet. You also had mentioned PyRevEng back then. I will try it. It will be very useful at this point. ___ 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.
Re: [time-nuts] 5370 firmware hacking status report
On Jul 25, 2011, at 2:32 PM, Tijd Dingen wrote: A quick check shows digikey sells them in single quantities, and has current stock. Good news. I hadn't checked for five months, but maybe my original search was faulty. Funny that they're $1.40 more expensive than the microcontroller ($10 vs $8.60 for 25 pieces). ___ 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] 5370 firmware hacking status report
In message 77e0fba5-aa78-4399-9562-d1274e109...@jks.com, John Seamons writes: I would worry a bit about the PLL locking too, but I have no idea how to actually measure it. I think the 1sec max gate-time is related to the eventcounter width, but it might be possible to simulate a wider counter in software. The obvious idea for advanced functionality is calculation of allan deviations -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] 5370 firmware hacking status report
Hi, the 5370 is capable of measuring up to 10s long time events or frequency/period with 10s gate time. (I.e. 2^39 * 19.53ps) Pressing 'external holdoff' activates external gating on 'EXT' input. Then you may apply a 10s long positive pulse from an external generator, with a few ms long pause, to the external input, getting 12 digits resolution. To have this longer gate time in firmware would be nice. Interesting would be to have even longer than 40 Bit arithmetic length by counting the overflow of the counter chain, and also, to get access to the full content of the arithmetic registers to calculate with higher precision externally. Or perhaps it is possible to realize a 'time stamp counter' on the 5370s hardware, to get zero dead time for T.I. measurements on 1pps comparisons. Frank ___ 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] 5370 firmware hacking status report
Poul-Henning Kamp wrote: In message77e0fba5-aa78-4399-9562-d1274e109...@jks.com, John Seamons writes: I would worry a bit about the PLL locking too, but I have no idea how to actually measure it. I think the 1sec max gate-time is related to the eventcounter width, but it might be possible to simulate a wider counter in software. The obvious idea for advanced functionality is calculation of allan deviations The PLL sample frequency is around 0.8MHz so that trigger rates approaching this will alter the PLL loop parameters. Trigger rates greater than the PLL sample frequency (200/256MHz) will likely cause lock to be lost. The 5359 (uses the same vernier oscillator assembly) overcomes this by using a digital sample and hold to set the VCO control voltage. However periodic auto calibration by closing the loop is required to avoid drift. Bruce ___ 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] 5370 firmware hacking status report
John, Fantastic job on reverse engineering the counter and then actually doing something to modernize it. I might guess implementing this on one of the counters out of 3 would be both educational and interesting. Ending up with a modern on the network counter. Took a look at your setup and bench. So the support for the 5370 is a HP vector network analyzer. Now thats some support. :-) I might tend to have the two flipped in the stack. So you are suggesting the potential to make this operational to a wider audience. Any thoughts on a timeline? I personally have no problems soldering in 40-60 wires from a daughter board as an example. Regards Paul WB8TSL On Sun, Jul 24, 2011 at 8:12 AM, Bruce Griffiths bruce.griffi...@xtra.co.nz wrote: Poul-Henning Kamp wrote: In message77E0FBA5-AA78-4399-**9562-d1274e109...@jks.com77e0fba5-aa78-4399-9562-d1274e109...@jks.com, John Seamons writes: I would worry a bit about the PLL locking too, but I have no idea how to actually measure it. I think the 1sec max gate-time is related to the eventcounter width, but it might be possible to simulate a wider counter in software. The obvious idea for advanced functionality is calculation of allan deviations The PLL sample frequency is around 0.8MHz so that trigger rates approaching this will alter the PLL loop parameters. Trigger rates greater than the PLL sample frequency (200/256MHz) will likely cause lock to be lost. The 5359 (uses the same vernier oscillator assembly) overcomes this by using a digital sample and hold to set the VCO control voltage. However periodic auto calibration by closing the loop is required to avoid drift. Bruce __**_ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/** mailman/listinfo/time-nutshttps://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.
Re: [time-nuts] 5370 firmware hacking status report
On Jul 24, 2011, at 12:32 AM, Poul-Henning Kamp wrote: I would worry a bit about the PLL locking too, but I have no idea how to actually measure it. I think the 1sec max gate-time is related to the eventcounter width, but it might be possible to simulate a wider counter in software. The obvious idea for advanced functionality is calculation of allan deviations Interpolator PLL unlock: From the schematic, each VCO control voltage gets limit checked by a comparator located on the 200MHz multiplier card. If either one goes out of range a latch gets set on the count chain board which shows up as a status bit in N0ST. That latch is what drives the red led on the top edge of the count board. I currently check it at the top of the 500 sample/packet loop. This is often enough since it gets latched even if the VCO drops out only once. Whether the comparator is good enough if you're on the edge of failure sampling at 100 K/sec is another matter. Event counter width: It seems to be 16-bits wide with an overflow bit also in N0ST. So extending the bit length in software is not impossible. I notice now that the N0 counter has an overflow as well. This explains why binary mode readout is limited to TIs 320 ns (typo in manual, it says ps). An HPIB binary connection has no way of dealing with software overflow from a 16-bit N0. And 16-bits @ 200MHz is about +/- 328 ns. In non-binary mode the software must be maintaining a 28-bit N0 counter for the max +/- 10 sec TI spec. ___ 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] 5370 firmware hacking status report
On Jul 24, 2011, at 11:18 AM, paul swed wrote: Took a look at your setup and bench. So the support for the 5370 in a HP vector network analyzer. Now thats some support. :-) I might tend to have the two flipped in the stack. So you are suggesting the potential to make this operational to a wider audience. Any thoughts on a timeline? I personally have no problems soldering in 40-60 wires from a daughter board as an example. 4396A NSA: I should have been more clear about that. I only use that box as a programmable HPIB master for testing. Nothing more. I really need to get a PCI or USB GPIB interface like everyone else. Anyone running John's GPIB Toolkit under Wine on Ubuntu? /insert Windows rant Rather than trying to replicate my painful development setup we really just need to get a proper board made. That Atmel eval kit alone is $200. The board needs a boot loader that lets you re-flash over the network (instead of spending money on a JTAG dongle or using the awful Atmel USB flasher). Has anyone used KiCAD for pcb layout? Also, I don't know anything about USB, so I could use some help. Atmel has an existing stack for the micro. Big advantages over using Ethernet if you don't already have a network setup. ___ 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] 5370 firmware hacking status report
In message 2774adf8-762d-45c4-b3c6-edb188691...@jks.com, John Seamons writes: On Jul 24, 2011, at 11:18 AM, paul swed wrote: I really need to get a PCI or USB GPIB interface like everyone else. Anyone running John's GPIB Toolkit under Wine on Ubuntu? /insert Windows rant https://github.com/bsdphk/pylt Big advantages over using Ethernet if you don't already have a network setup. Ethernets big advantage is that it is galvanically isolated, USB is not. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] 5370 firmware hacking status report
Hi I would check that things like Win 7 64 bit are happy with the USB stack on the micro. I'm not selling anybody MS stuff, but it limits your audiance if there's a compatibility issue. Some USB stacks are a lot better than others (both embedded and at the OS level). Ethernet is going to be functional on any modern OS. Lots of variables... Bob On Jul 24, 2011, at 4:30 PM, John Seamons wrote: On Jul 24, 2011, at 11:18 AM, paul swed wrote: Took a look at your setup and bench. So the support for the 5370 in a HP vector network analyzer. Now thats some support. :-) I might tend to have the two flipped in the stack. So you are suggesting the potential to make this operational to a wider audience. Any thoughts on a timeline? I personally have no problems soldering in 40-60 wires from a daughter board as an example. 4396A NSA: I should have been more clear about that. I only use that box as a programmable HPIB master for testing. Nothing more. I really need to get a PCI or USB GPIB interface like everyone else. Anyone running John's GPIB Toolkit under Wine on Ubuntu? /insert Windows rant Rather than trying to replicate my painful development setup we really just need to get a proper board made. That Atmel eval kit alone is $200. The board needs a boot loader that lets you re-flash over the network (instead of spending money on a JTAG dongle or using the awful Atmel USB flasher). Has anyone used KiCAD for pcb layout? Also, I don't know anything about USB, so I could use some help. Atmel has an existing stack for the micro. Big advantages over using Ethernet if you don't already have a network setup. ___ 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.
Re: [time-nuts] 5370 firmware hacking status report
On Jul 24, 2011, at 2:40 PM, Poul-Henning Kamp wrote: Ethernets big advantage is that it is galvanically isolated, USB is not. You had mentioned this issue in February. And since I currently flash using USB I went ahead and bought the evaluation card for the Analog Devices ADuM4160 power/signal isolator chip (see last pic on jks.com). Even though I programmed the GPIO pins on the micro for open drain I didn't know if the +5 on the USB from the host computer would fight the signals from the 5370. Plus I didn't want the ground loop. So the isolator chip splits the power domains and the micro is powered by +5 from the 5370. Works great. But I haven't found anyone who sells the chip in small quantities yet. You also had mentioned PyRevEng back then. I will try it. It will be very useful at this point. ___ 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] 5370 firmware hacking status report
Some progress since February's discussion: My m6800 emulator running the 5370 firmware has been moved from the Linux box to a little 32-bit microcontroller on it's own small evaluation-kit board. Pictures here: http://jks.com (click on images for larger versions) You talk to it over an Ethernet connection. The 5370 device bus connects to the general-purpose I/O pins of the micro. Since the micro has 256KB Flash 128KB SRAM no off-chip memory is required. Everything just fits: emulator, firmware, lightweight TCP/IP stack, minimal C runtime, device drivers, performance hacks, ... All the front panel controls seem to work as expected. The operator verification section of the manual checks out. The HPIB hardware remote programming work, but I have a limited ability to test it currently. I have no computer-based GPIB card yet, just a 4396A with HPIB + Instrument Basic (yuk). But I also have a mode that fools the firmware into thinking the 5370 has the HPIB card installed (when it doesn't) and instead sends the transactions over Ethernet (USB also possible). More about this in a bit. Measurement performance is improved 40% on average and as much as 70% for some functions (see the spreadsheet and charts). The ultimate goal is to produce a drop-in replacement for the CPU card which would also allow you to toss the ROM card (older 5370s) and HPIB card. You'd get serial, Ethernet and USB connectivity to replace the HPIB. Now all this is fine, and somewhat amusing, but it's not clear there is any particular advantage. It's not as though there are piles of 5370s lying around with dead or missing CPU cards. Or that it's impossible to deal with HPIB anymore. One interesting possibility is adding new front-panel accessible measurement functions. Since the emulator has complete bus access it can detect new key press combinations before the firmware does and go into a mode where it gathers raw TI samples, processes them, and puts the results in the display. When an existing key sequence occurs the firmware is resumed and it doesn't even know it was paused while the new function was running. But I discovered something else that's even more interesting (note that I am relatively new to this time-nut stuff, so please correct my nutty mistakes). There was a discussion about how the 5372 is nice because of the high-speed readout option and the lack of dead-time, but how it doesn't match the 5370 one-shot resolution. The 5370 of course has this binary HPIB mode to get raw TI samples sent as fast as possible (roughly 6000/sec). I decided to try the same thing but from C code running on the (much faster) micro. I disassembled the firmware loop that reads samples from the TI count chain registers into the HPIB data-out register. I found that I could move 100K samples/sec out of the TI regs into a memory buffer (not a typo, one hundred K). Adding code to stream 512 samples per Ethernet packet back to a host computer dropped the rate to 80K/sec. The screen shot of the logic analyzer shows this process. This trace has little jitter so as long as the host on the other end is reasonably fast, and the network isn't loaded, this streaming rate should be sustainable. Obviously there is huge dead-time while the network code runs, but there might be ways around this. I should mention that because I have more processing power now on the instrument side I can do some pre-computation and only send 2-bytes per sample as opposed to the 5370 which sends 5. So 512 * 2 bytes = 1024 bytes/packet. The last screen shot is of the host side. So far all the TI values seem to be reasonable. ___ 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] 5370 firmware hacking status report
John Seamons wrote: Some progress since February's discussion: My m6800 emulator running the 5370 firmware has been moved from the Linux box to a little 32-bit microcontroller on it's own small evaluation-kit board. Pictures here: http://jks.com (click on images for larger versions) You talk to it over an Ethernet connection. The 5370 device bus connects to the general-purpose I/O pins of the micro. Since the micro has 256KB Flash 128KB SRAM no off-chip memory is required. Everything just fits: emulator, firmware, lightweight TCP/IP stack, minimal C runtime, device drivers, performance hacks, ... All the front panel controls seem to work as expected. The operator verification section of the manual checks out. The HPIB hardware remote programming work, but I have a limited ability to test it currently. I have no computer-based GPIB card yet, just a 4396A with HPIB + Instrument Basic (yuk). But I also have a mode that fools the firmware into thinking the 5370 has the HPIB card installed (when it doesn't) and instead sends the transactions over Ethernet (USB also possible). More about this in a bit. Measurement performance is improved 40% on average and as much as 70% for some functions (see the spreadsheet and charts). The ultimate goal is to produce a drop-in replacement for the CPU card which would also allow you to toss the ROM card (older 5370s) and HPIB card. You'd get serial, Ethernet and USB connectivity to replace the HPIB. Now all this is fine, and somewhat amusing, but it's not clear there is any particular advantage. It's not as though there are piles of 5370s lying around with dead or missing CPU cards. Or that it's impossible to deal with HPIB anymore. One interesting possibility is adding new front-panel accessible measurement functions. Since the emulator has complete bus access it can detect new key press combinations before the firmware does and go into a mode where it gathers raw TI samples, processes them, and puts the results in the display. When an existing key sequence occurs the firmware is resumed and it doesn't even know it was paused while the new function was running. But I discovered something else that's even more interesting (note that I am relatively new to this time-nut stuff, so please correct my nutty mistakes). There was a discussion about how the 5372 is nice because of the high-speed readout option and the lack of dead-time, but how it doesn't match the 5370 one-shot resolution. The 5370 of course has this binary HPIB mode to get raw TI samples sent as fast as possible (roughly 6000/sec). I decided to try the same thing but from C code running on the (much faster) micro. I disassembled the firmware loop that reads samples from the TI count chain registers into the HPIB data-out register. I found that I could move 100K samples/sec out of the TI regs into a memory buffer (not a typo, one hundred K). Adding code to stream 512 samples per Ethernet packet back to a host computer dropped the rate to 80K/sec. The screen shot of the logic analyzer shows this process. This trace has little jitter so as long as the host on the other end is reasonably fast, and the network isn't loaded, this streaming rate should be sustainable. Obviously there is huge dead-time while the network code runs, but there might be ways around this. I should mention that because I have more processing power now on the instrument side I can do some pre-computation and only send 2-bytes per sample as opposed to the 5370 which sends 5. So 512 * 2 bytes = 1024 bytes/packet. The last screen shot is of the host side. So far all the TI values seem to be reasonable. ___ 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. One potential problem with very high sample rates is that the PLL associated with the 5370's 200MHz vernier oscillators fail to lock if the sample rate is too high. Bruce ___ 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] 5370 firmware hacking status report
Now all this is fine, and somewhat amusing, but it's not clear there is any particular advantage. It's not as though there are piles of 5370s lying around with dead or missing CPU cards. Or that it's impossible to deal with HPIB anymore. One interesting possibility is adding new front-panel accessible measurement functions. Since the emulator has complete bus access it can detect new key press combinations before the firmware does and go into a mode where it gathers raw TI samples, processes them, and puts the results in the display. When an existing key sequence occurs the firmware is resumed and it doesn't even know it was paused while the new function was running. One thing that would be really nice is if you could do frequency readings with a 10-second gate time, as opposed to the current maximum of 1 second. That would make the LSD meaningful instead of completely random, as it is now. -- john, KE5FX ___ 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.
