Telecon tomorrow (Thursday) @ 5 pm Eastern time

Hi all,

Telecon tomorrow (Aug. 5 in North America, Aug. 6 in Australia) at the regular time: 5 pm Eastern (2 pm Pacific, 11 am Hawaii, 23.00 European, 7 am Eastern Australia). More progress from Andrew Macdonald over the past 2 weeks on layout for the new ALTAIR form-factor version of the ORCASat transimpedance amp board; and we also have further updates to AIFCOMSS. Progress also continues to be made on optical simulation and on measuring electrical characteristics of the photodiode readout. More discussion items for tomorrow's telecon include: flight/telescope plans and tests; construction and lab tests of the new gondolas/payloads; light sources and light source modelling; goniometric and pre- and post-flight calibration; propulsion work; nanosat bus and payload solid models; computing / website / TWiki forums and e-mails; grant applications; and recap of schedules. I'll send a progress report before the telecon tomorrow.

Here's how to connect:

1) Open Skype on your computer (note that of course, you should first install Skype, http://www.skype.com, on your machine if you haven't already).
2) In the "Contacts" menu, add me ( jalbertuvic ) as a contact, if you haven't already.
3) Just wait for me to Skype-call you at the usual time (5 pm Eastern, 2 pm Pacific, etc).
4) If there is any trouble, or if you don't get a Skype-call for some reason and would like to join, please just send me an e-mail (jalbert@uvicNOSPAMPLEASE.ca).

Here's the tentative agenda:

I) Flight & telescope plans, and upcoming tests
II) Construction, drop tests, and other tests of the new gondola and payload
III) Diffused light source and its modelling, pre- and post-flight calibration, and goniometric calibrations
IV) Solid modelling
V) Computing/website, including recent flight control and simulation progress
VI) Grant applications
VII) AOB

Talk to you all tomorrow, thanks!!!
justin

-- jalbert - 2021-08-05

Hi all,

My apologies for the delay! -- here's an update on recent ALTAIR balloon work, minutes of the last meeting on July 8 (attendees Arnold Gaertner [NRC] and me), and a reminder of the telecon in 15 minutes(!) from now:

Andrew Macdonald has made progress on the layout of the ALTAIR version of the transimpedance amplifier board. You can see an image of the present state of his mask layout at:

(as of the end of last week, Jul. 30). That's certainly a significant improvement from two weeks prior:

but, there are still a few lines that need to be placed. Also, Andrew is now adding a clock oscillator to the boards, per this important new note from Evan:

On July 29, 2021, Evan Moore wrote:

> I noticed a bug in how we do sampling with the ADCs of the TIA. I
> have corrected for it in software on ORCASat, but there is a better
> hardware solution that might be worth looking into for ALTAIR.
>
> The problem comes from a conflict between how we desire *simultaneous*
> measurements from the multiple ADCs on the ORCASat board, and how we let
> the ADCs govern their own data delivery rate. The ADCs we are using
> (ADS124S08) have an internal 4.096MHz oscillator that they use by
> default to govern the timing of producing samples, operating their
> digital side, etc. They also have an external clock input line that they
> can use to bypass this oscillator and use an external source instead
> (you might see where I am going with this...).
>
> The ADCs are quite consistent about producing steady measurements
> temporally relative to themselves but on a device-to-device basis
> there is some inconsistency. That 4.096MHz oscillator is only 1.5%
> accurate, meaning that one device might produce measurements a fraction
> of a microsecond faster than another device (and indeed I can and have
> measured this happening). Not a lot of individual difference but it
> starts to add up. In the current design during an illumination, the
> first few samples produced this way by two devices are quite close (i.e.
> taken virtually at the same time) but since one device is slightly
> faster than the other, one starts to get ahead, and by 15 seconds (the
> length of our illumination) I have measured one device to have produced
> 20 more samples than the other, i.e. it is ahead by 10 ms when
> generating samples at 2kHz each. Which is not great when you want
> simultaneous measurements. This is all because those internal
> oscillators won't be perfectly matched.
>
> Now the workaround I implemented in the ORCASat design was to instead of
> letting the ADCs run on continuous conversion mode (whereby they
> endlessly generate data and spit it out over the bus) I put them into
> single-shot mode, and have their sampling process triggered via the
> START line (pin 8 of the ADS124S08), since this line is shared by both
> devices. This way they will always start a sampling process
> simultaneously, at the cost of some overhead by the payload MCU to
> produce that triggering pulse train and "wakeup" time on the ADC side
> from entering and exiting single shot mode. We still make the 2KHz
> sampling speed, but we can't go any faster than this, whereas before
> there was a little wiggle room.
>
> The better solution in my opinion (and why I am telling you this Andrew)
> I think would be to implement an external clock line on that exposed pin
> (pin 17 of ADS124S08) dedicated to this purpose. Whatever you are using
> to pull data out of the ADCs you could also use to generate a 4.096MHz
> pulse train, and have that tied to both clock lines of both (or more)
> ADCs. This would effectively sync all devices tied to the clock line in
> this way. You would have to be careful about signal delay as 4.096MHz is
> getting into the higher frequency range where those kinds of things
> start to matter, but overall I think the end product would be more
> robust.

I responded with the question:

> Could the SCLK line from the SPI bus (which is already on the board, and
> already connected to pin 11 of ADS124S08) be used for this purpose, at
> least in principle? -- i.e., could SCLK connect to pin 17, in addition to pin
> 11? What would happen if one were to do that?

Evan's answer was "not a good idea!":

> You cannot use the SCLK line of the SPI bus for this purpose. The MCLK
> (what I will call that 4.096MHz oscillator signal) needs to be running
> the entire time the ADC is doing things, but the SCLK can only be
> active during an active transmission, and at no other time else the
> ADC will get messed up as it will think you are transmitting commands to
> it. You would need a dedicated line for the MCLK.

Thus, Andrew's solution will be:

> I recommend that we add an onboard oscillator than can be bussed to
> all three boards through the stacking connector. Only one board in the
> stack will have the IC populated and the other two boards sub to that one.

However, I just noted 15 minutes ago:

> I had forgotten a quite important point!: Due to where space exists within
> the ALTAIR payload, my plan had been (i.e., ever since we first started
> thinking about these boards, like 3 years ago or so) to have two of these
> three TIA boards stacked together (on one side of the ALTAIR payload),
> however the third board on the other side of the ALTAIR payload (and
> thus not stacked with the other two). (That's just where the space for
> them exists.) Would/will this be a problem? I.e. would/will there be a
> reasonably easy way (e.g., a wire, or small bundle of wires) to get the
> clock signal from the two stacked boards to the unstacked board,
> without all 3 being stacked together?

So, I am hopeful that we can turn the TIA board stacking connector out into a small bundle of wires to go out to the third, unstacked TIA board within the ALTAIR payload (I think that should be doable without too much trouble). And hopefully, Andrew will have completed layout files for us for the next telecon.

Summer students Colton Broughton, Sarah Alshamaily, and Will Stokes are working on installing AIFCOMSS ( https://github.com/ProjectALTAIR/AIFCOMSSwithCUPredictorTest ) on their laptops, and seeing what updates need to be made on it. I've now updated AIFCOMSS to work with the recent Cesium v1.83, as well as the instructions, and at least Colton reports success with this update and those instructions. The next two things that we know most definitely will need updating (or, rather, creating) are the station-keeping software for AIFCOMSS, and the online command-handling within the onboard Arduino software -- and I'll be working on those over the next 2 weeks.

I still need to test out out Radiometrix SHX1 144 MHz transceiver modules that were returned to us last month from Radiometrix (following their firmware update to fix the BUSY output):

as well as our two 144 MHz Raveon M8S data modem transceivers:

Once we get our 144 MHz transceivers settled and back into the ALTAIR gondola, we'll do some outdoor drop testing of the actual gondola. (We've done all the outdoor drop tests I can think of doing with our dummy gondola.)

And we also still need to test out our new DFRobot SEN0177 payload aerosol monitors that we have here:

I've begun to look some more at MEEP (https://meep.readthedocs.io/en/latest/) for finite-difference time domain (FDTD) simulation of integrating sphere output, but I haven't yet had time to make any significant progress there -- I'm hoping to do that in the next couple of weeks. It will be interesting to compare that with ray tracing simulations, when I can get a chance to do that!

Engineering students Josh Gage and Evan Moore found that the "wings" that Josh had found in the laser diode light output distributions:

were due to how the diode was mounted in the heat sink. When the diode is mounted properly and carefully, the wings go away.

We also have our 10 Hamamatsu S12698-01 photodiodes and 3 Thorlabs FDS100-NOCAN photodiodes (those Thorlabs ones have their windows removed) here in Victoria:

I've given them to Evan to try out -- he's taking a few weeks to ramp up, and will produce some linearity, etc., plots from them soon.

The survey-tripod-mounted device to cross-check yaw-pitch-roll information from the gondola (e.g., on days before/after flights) is also constructed now, thanks to Mark Lenckowski -- photo at:

and all that remains to be done is to finish the small fitting between the device and the bottom of the payload. The purchased hardware in it includes both the survey tripod (http://www.cpotools.com/cst-berger-60-alwi20-o-aluminum-tripod-with-quick-release--orange-/cstn60-alwi20-o,default,pd.html), two adjustable angle mounts (http://www.thorlabs.com/thorproduct.cfm?partnumber=AP180), and a rotation mount (https://www.thorlabs.com/thorproduct.cfm?partnumber=RP01). That last fitting to attach (temporarily, pre-or post-flight) the upper adjustable angle mount to the payload landing gear has been started and will be completed here in the next couple weeks.

We're currently revising the draft initial contractual agreement from our colleagues at Globalstar Canada regarding 2 initial SPOT Trace devices (and their service plans) for the educational side-project for the upcoming NATO SPS application, in which classrooms in elementary and high schools could launch company-donated SPOT Traces using party balloons (or a more environmentally-friendly version thereof), and track them to learn more about winds at different levels in Earth's atmosphere.

Houman will send Cordell and/or us updated sections of his master's thesis soon -- that information will be extremely useful to us going forward. Also, Susana and Nathan, it would be very helpful for us all to get the JHU students' final writeup when you have a chance.

Next grant application will be a NATO "Science for Peace and Security" application (together with Australian colleague partners).

Our next telecon is in 15 minutes from now -- see below for Skype instructions.

Cheers, talk in 15 mins (!) from now -- thanks all!

justin

-- jalbert - 2021-08-05