RNO-G IGLU amplifier includes cable delay

[sjoerd-bouma]

@christophwelling
The measurement currently used for the RNO-G IGLU amplifier response was taken with a 50m fibre cable, and currently includes the delay due to this cable. We should probably remove that...

Plot is of the amplifier response of the IGLU (channel 0) and SURFACE (channel 12) amplifiers in the time domain (i.e. as applied to a delta pulse at t=0).

[shallmann]

@fschlueter doesn't seem we are already including this in the database detector.
using the db detector, I seem to get this for station 21

 7: 639.813999907825,
 6: 736.7796761804569,
 5: 835.2873499410072,
 0: 968.5987543818476}

Compared to numbers I got from Sjoerd (using the json I think)

Ch.  0: 717 ns
Ch.  5: 584 ns
Ch.  6: 485 ns
Ch.  7: 388 ns
Ch. 13:  46 ns

The latter fits much better with deep/shallow coincident pulses for high station multiplicity events I am seeing (planes or similar, TBC). So we should implement the delay in the database detector

@sjoerd-bouma not sure if the measurements were taken at ECAP at the time, but did you already determine a precise value for this offset when you looked at deep/shallow coincident wind-noise?

[fschlueter]

What you get with the DB is (should be) the total delay of the system, not only the fiber cable but also the amplifiers and jumper cables, and so on. However, I wonder if that can make such a big difference of ~250 ns. I am worried that for the deep channels we still have a reference cable in the total response which we are not able to subtract. I talked about that with @philippwindischhofer. This additional cable should be not a big issue when only working with deep channel but when comparing deep with shallow it will...

[fschlueter]

what is the value you get for channel 13 with the new dB? I assume it is much close to 46ns and does not add ~250ns

[sjoerd-bouma]

@fschlueter Yes, this is most likely what's happening. The DB values for the shallow channels are more realistic.

@shallmann If you mean the exact delay for the 50 m cable, I don't have a value for that - I would have hoped that somewhere in the database the response for this cable could be found, but it sounds like that might not be the case.

[philippwindischhofer]

Hi all!

@sjoerd-bouma Indeed we don't currently have the capabilities to measure absolute fiber delays with adequate precision. That's why (even in principle) we're not able to provide a delay measurement for the 50m fiber.

@shallmann I don't know what the context of your question is (so what I'm going to say is perhaps not going to be extremely relevant), but when I compared cable delay differences for deep-deep channel pairs, the DB and the detector description json matched pretty well. (See example plot attached.)

CH0_CH3.pdf

[shallmann]

@philippwindischhofer the relative difference deep to deep channels should be fine, yes. It should be only an overall offset of the measurement setup including 50m cable that was not subtracted for the deep channels. I am fine with including a cable component with weight -1 that has an overall ~250ns ish (the best value we can find - I can dig if I see anything in the database), since starting with something remotely correct is better than being 250ns off when you try to fit/calibrate with shallow and deep together.

[shallmann]

Ok, I think I can narrow things down.
There is, as I would have expected, already a "Golden_boards_Erlangen_2021" component in the signalchain that gets added with weight -1 (i.e. subtracted). When I look directly in the database, I see a time_delay: 259.96028111444735 for the S21, which looks correct.

So everything (as good as we can do for now without additional calibration) is there.

I can go dig myself why this did not get picked up correctly when I requested the signal chain from the database.

[philippwindischhofer]

Yes, agreed! Thanks @shallmann!

[shallmann]

So here is what goes wrong:

DEBUG:NuRadioReco.RNOGdetector:Checking for station 21 at 2024-08-02 00:00:00 ...
DEBUG:NuRadioReco.RNOGdetector:Station 21 is commissioned!
DEBUG:NuRadioReco.Response:Remove a time delay of 260.35 ns (weight 1) from iglu_board
DEBUG:NuRadioReco.Response:Remove a time delay of 260.19 ns (weight 1) from drab_board
DEBUG:NuRadioReco.Response:Remove a time delay of 259.96 ns (weight -1) from golden_downhole_components_1
DEBUG:NuRadioReco.Response:Remove a time delay of 11.92 ns (weight -1) from golden_downhole_components_2
DEBUG:NuRadioReco.Response:Remove a time delay of 714.47 ns (weight 1) from optical_fiber
DEBUG:NuRadioReco.Response:Remove a time delay of 0.94 ns (weight 1) from radiant_response
DEBUG:NuRadioReco.Response:Remove a time delay of 4.53 ns (weight 1) from coax_cable

Both iglu and drab got measured with the golden_downhole_components_1 chain, but it is only subtracted once.
There are two solutions I see:

• Change the allowed weights to integer (instead of [-1,1])
• Add the golden_downhole_components_1 a second time.

I don't care which one to attempt. I tend to favor the first. Maybe @fschlueter can tell me right away what I need to do / can go wrong. Eg. I can imagine that the items need to be unique to get picked up it it is kind of a dict.

[fschlueter]

I think in both of your solutions the amplitude would be wrong afterwards (But I am not sure).

What I believe might be the situation is this one (hope that makes sense to you and is readable):

[fschlueter]

So if you subtract another R(I_G F_G D_G) = golden_downhole_components_1 you reduce the amplitude by ~60dB

[fschlueter]

The entire thing works if F_G = F_X but this is unfortunately not case for those measurements. @philippwindischhofer for your measurement campaign you made sure that it is right?

[philippwindischhofer]

Yes ... with the added complication that we started using another F_G halfway through the measurements, because its connectors were getting worn out and it needed to be replaced. But we measured as best as we could the ratio of the two.

[philippwindischhofer]

Do you know what F_X looked like for the measurements we have in the DB now? If it's the ratio F_G / F_X that produces the ~250ns delay, and F_G was itself a 50m fiber, then F_X should be pretty short?

[shallmann]

@philippwindischhofer if I interpret my list of subtracted elements above correctly, you are referring to 11.92 ns (weight -1) from golden_downhole_components_2 ... so yes, that is pretty short.

I was discussing with Felix, that it might not be pretty, but the best thing we can do for now to include an additional signal chain component with just the missing fiber delay, unless @philippwindischhofer you have a better idea? Where is the I_X, D_X, and the Golden Fiber now - if we could "simply" measure this, that would solve the issue, right?

[fschlueter]

Maybe Kaeli knows

[philippwindischhofer]

@shallmann I agree---adding another "dummy" signal chain component to parameterize our ignorance sounds like the right way forward. We only have to be careful to avoid generating the impression that we have more precision than we actually do. (As far as I understand the DB does not yet have the capability to include uncertainties.)

@fschlueter @shallmann as far as I understand, F_X was an internal fiber of old ARA electronics that were used back then in those original measurements. These components are still in the lab in Chicago, but the connectors etc. are not available to interface with our "standard" IGLU-fiber-DRAB measurement setup. Kaeli will doubtlessly know more.

F_G should be back in Erlangen (Maddalena took it back after this year's measurement campaign)---but again, we have the problem that we cannot "simply" measure absolute fiber delays.

[fschlueter]

@philippwindischhofer do you know what length F_X has?

[fschlueter]

@KaeliAutumn

[philippwindischhofer]

Hi @fschlueter I attach some pictures of the RFoF Tx and Rx units that were used for these measurements. I unrolled one pigtail and measured it to be about 1m / 5ns long. During the baseline / reference measurement I assume the two pigtails were simply connected together, which would be consistent with a 2m / 10ns delay that @shallmann was reporting on above.

[philippwindischhofer]

If we want a more precise value, perhaps it's worth to plot the (fiber - baseline) measurements vs. fiber length and extract the slope, which could then be included as an "analytical" fiber.