Give RAW captures their own output stream and gate reads on RAWENABLE - #29
mikelangmayr wants to merge 8 commits into
Conversation
# Conflicts: # utils/fits_writer.cpp
|
|
||
| // Raw is captured with the frame, so a buffer filled before RAWENABLE was set | ||
| // reports zero and raw_geometry() falls back to inferring from the config keys | ||
| if (this->frameinfo.bufrawblocks[index] == 0 || |
There was a problem hiding this comment.
isn't this check in raw_geometry()?
There was a problem hiding this comment.
Yes, it was. raw_geometry() now sets a from_config flag in the one place that makes the decision, and read_raw warns off that instead of re-testing the buffer fields.
| constexpr int MODTYPE_ADM = 17; | ||
|
|
||
| // First backplane slot an AD or ADM module may occupy, which RAWSEL indexes from | ||
| constexpr int AD_SLOT_FIRST = 5; |
There was a problem hiding this comment.
Does every AD module start at slot 5?
There was a problem hiding this comment.
All ADCs are slots 5-8 only
There was a problem hiding this comment.
Slots 5-8 only, so the constant holds. Comment now states the full range rather than just the first slot.
| std::shared_ptr<const Common::FitsKeys> ArchonController::raw_frame_keys() const { | ||
| // RAWSEL indexes four channels per slot, starting at the first AD slot | ||
| const int channel = this->rawinfo.adchan; | ||
| const int slot = AD_SLOT_FIRST + channel / MAXNADCHAN; |
There was a problem hiding this comment.
This might be an inherited problem, but MAXNADCHAN=4 but there's also a MAXADCCHAN and MAXADMCHAN. Either way, this arithmetic won't work for either ADC or ADM, and certainly not for both.
There was a problem hiding this comment.
Agreed, and I have not changed it yet because I do not want to guess the mapping. The manual documents RAWSEL only for AD modules: 0 to 15, four per slot, "0 for channel 1 of the ADC module in slot 5 through 15 for channel 4 of the ADC module in slot 8". It says nothing about reaching an ADM channel, and an ADM has 18 per slot. This chassis is mixed, slot 5 reports type 17 and slot 6 type 2, so RAWSEL=4 is genuinely ambiguous between them.
Does RAWSEL address ADM channels at 18 per slot, or is it fixed at 4 per slot regardless of the installed module?
There was a problem hiding this comment.
Pulled the full SYSTEM report off the controller. It locates the boards but does not settle the mapping:
- slot 6 is
MOD6_TYPE=2, a documented AD, rev 10 - slot 5 is
MOD5_TYPE=17, rev 1, undocumented (the manual stops at16+: Unknown) - slots 1-3 are
MOD1..3_TYPE=16, all rev 0
STATUS reports only MODn/TEMP for both slots 5 and 6, so it cannot confirm 17 is an ADM by channel count. That equation stays an assumption already baked into the header as MODTYPE_ADM = 17.
What does settle the slot arithmetic is the documented RAWSEL range of 0 to 15, which is exactly four slots times four channels and so cannot address an 18-channel ADM at all. So dividing by four identifies the slot correctly; what it cannot identify is which of an ADM channel set you received.
Given that, does recording the derived slot plus its MODn_TYPE read right to you, with the divisor named for the documented four-per-slot RAWSEL range instead of borrowing MAXNADCHAN?
There was a problem hiding this comment.
Withdrawing what I said above. The Archon GUI source settles it and contradicts the manual.
archon.h carries the full type table, so 16 and 17 are not unknown at all:
#define MOD_TYPE_ATLAS 6
#define MOD_TYPE_DRIVERX 16
#define MOD_TYPE_ADM 17
#define MOD_TYPE_UNKNOWN 18
More to the point, the GUI builds its Raw Channel Select from for (i = 1; i <= 72; i++) and stores RAWSEL = currentIndex(), so RAWSEL spans 0 to 71, not 0 to 15. 72 is 4 slots times 18 channels, which is the ADM layout. The manual range is stale.
That leaves two incompatible strides, 4 per slot from the manual and 18 per slot from the GUI, and no way for the host to tell which the firmware uses on a mixed chassis. This one has DriverX in 1-3, ADM in 5 and AD in 6, so RAWSEL=4 is slot 6 under one reading and slot 5 under the other.
So you were right and the derivation is coming out. Recording RAWSEL verbatim plus the MODn_TYPE of each of slots 5-8 claims nothing the hardware has not told us.
Separately, MODTYPE_UNKNOWN = 16 in our header is wrong, since 16 is DriverX and 18 is the sentinel. It is currently unused so nothing misbehaves, and I will keep it out of this PR.
|
This branch has not been deployed
3 participants
<base>_<frame>_raw.fits) and its own shared-memory segment (<segment>_raw) instead of colliding with the image or resizing its streamraw readrefuses whileRAWENABLEis 0, since the Archon captures raw alongside the frame and a controller with capture off is indistinguishable from one reporting nothingraw_geometry()decides in one place whether it fell back to the config keys, andraw readwarns off thatRAWSELverbatim, theMODn_TYPEof every slot it could address, and the four geometry keysRAWSEL: the manual documents four channels per slot over slots 5-8, the Archon GUI offers 72 selections which is eighteen per slot, and the two resolve differently on a mixed chassis16+: Unknownraw read