v1.0 testing

[hartytp]

@gkasprow what's the status of production/testing for Pounder v1.0?

[pkozakiewicz]

@hartytp We are just doing SMT assembly at the moment. I'll be able to bring those boards to Greg this week.

[jordens]

@gkasprow It might be possible to get some basic testing firmware (i.e. set clock to XO, initialize DDS, output some frequency on all four channels) done so you can do the bulk of the hardware debugging within the next two weeks. If that helps you with the smoke-testing and catches some hardware issues early, it would be great to do. @ryan-summers would be working on that.

[gkasprow]

Sure. For now, I can only check only power supplies.

[hartytp]

Great! Thanks all for the update

[ryan-summers]

@gkasprow I've implemented a custom firmware image for pounder bringup that will configure the AD9959 (DDS) to output waveforms on CH1-CH4 at various frequencies (CH1: 80MHz, CH2: 80.001 MHz, CH3: 90 MHz, CH4: 90.001 MHz).

This firmware communicates with the I2C GPIO expander on Pounder to power the on-board oscillator and select it for use by the DDS. There are a few indications:

1. All Pounder LEDs are illuminated - This indicates that communication with the GPIO expander over I2C was successful.
2. Stabilizer LEDs 1-3 are illuminated - This indicates that a self-test of the DDS quad SPI interface passed.
3. Stabilizer LED 0 is rapidly toggled (MHz range) if the device did not encounter any errors.
4. Regardless of (1) and (2), the respective waveforms are generated on CH1-CH4. If either (1) or (2) above did not pass, these waveforms may or may not be present (either due to communication or clocking issues).

This firmware should be flashed identically to however you have flashed Stabilizer previously. The repository for the new firmware is here: https://github.com/quartiq/pounder-bringup

If you need any help with it, feel free to get in contact with me.

[jordens]

NB: current master of cargo-flash+probe-rs support that chip and e.g. stlink-v3 nicely.

[jordens]

@gkasprow do you have the completed board? Any first impression?

[gkasprow]

Yes. I received it yesterday.

[gkasprow]

the IC22 voltage is wrong. It is 6.3V instead of 7V

[gkasprow]

the FB voltage is 0.696V

[gkasprow]

OK, I assumed FB is 0.8V because the DS says it can work from 0.8V to 17V. In fact, we have 0.7V. So the voltage divider is wrong.

[gkasprow]

The R136 must be corrected. Instead of 5k6, there should be 4k7

[jordens]

@gkasprow We developed a testing firmware for you as discussed. Did you try that? Did you just check power supplies or will there be more testing on your end? TS seems to be about to ship these devices out but I have no idea how much testing they have seen.

[gkasprow]

I managed to check the power supplies and fix one bug. Due to the very urgent and complex COVID-related project, I didn't do more. Hopefully, in a month I will come back to reality...

[jordens]

@dtcallcock what do you think? We won't be able to dig very deep into hardware debugging.

[dtcallcock]

I'm happy to just hit pause for a month until @gkasprow can do more testing if everyone else is.

[jordens]

I'd like to push for v1.1.

We did some basic smoke testing and it works fine apart form the issues we submitted. Nothing surprising on a spectrum analyzer scan or on the quick-and dirty beat between two channels.

@dtcallcock @hartytp did you guys test and maybe characterized it a bit?

@gkasprow Do you want to fork an issue for R136?

[hartytp]

I'm not going to get around to looking at this any time soon I'm afraid. Not sure about @cjbe or @dnadlinger

[dtcallcock]

Unfortunately we don't have anyone here with the skills to seriously contribute to Pounder testing yet.

[dnadlinger]

I didn't test it yet, as the near-term project for which I would have needed it (PLL for fibre noise cancellation) didn't materialise (yet), and AFAIK also would have needed extra firmware work. @cjbe / @vmsch Are you planning on using Stabilizer/Pounder for any of the laser systems currently being materialised?

[cjbe]

I am planning on using Pounder for both the PDH lock and phase noise cancellation for the new 729, but have not had bandwidth to test (nor a laser until Christmas).

[vmsch]

We plan to switch to stabiliser at some point for B-field stabilisation, but not in the next few months.

[jbqubit]

I've recently locked a noisy 435 nm ECDL to a 100 kHz cavity. Along the way we found there were fast frequency excursions that required loop bandwidth of about 10 MHz. The NIST SERVO latency was far too large. We finally ended up using MogLabs FSC.

Curious what the expected Pounder latency is. Has it been measured yet in the lab? Context is discussing with @gkasprow if Pounder will totally supersede NIST SERVO. Helps plan for which lasers Pounder will work with for cavity locks.

The NIST SERVO "is capable of feedback bandwidths up to roughly 1 MHz (limited by the 320 ns total latency)". Real-world latency may be greater if additional IIR filters are used. See Table 1. https://arxiv.org/abs/1508.06319

Toptica FALC is all-analog with 15 ns delay. MogLabs Fast Servo Controller nist 40 ns.

[dtcallcock]

Pounder is just a PDH lock signal generator. I think you are really asking a question about the Fast Servo. The nice thing about Pounder is that it will plug into the Fast Servo instead of requiring an extra box like the NIST/Toptica/MogLabs parts you reference above.

Of course, the Pounder signal path adds some latency, especially from the low pass filter in the op-amp buffer. I imagine it is comparable to anything else you might use though (once you've depopulated the LPF).

[jbqubit]

Yes, I do mean Pounder + Fast Servo. Looks like it's still early in Fast Servo testing & firmware development so it will be some time before its real-world latency can be measured, eh?

[gkasprow]

We are currently porting NIST SERVO firmware to run on FastServo - we are replacing the USB communication channel with ZynQ AXI. The rest of the gateware will be the same.