Okay, I have a lot of covers, so I'm going to get straight into it.
So we have a very simple agenda.
There's some tedious stuff on Vita49.
I'm going to take you through and then we're going to do cool stuff with the Wingerloat telescope.
But it's a package deal, so you have to get both for me.
So first, a few words about the Wingerloat telescope.
I think a lot of you are familiar with it already.
I've already presented here earlier on the Wingerloat telescope.
Built in 1955, inaugurated 1956, mainly built for doing hydrogen line research,
has been active for research until and of the 90s.
Then decommissioned and early 2000s was taken over by a volunteer organization called Cameras,
of which Paul and I are both volunteers, representatives here.
So right now, let me see, does it work?
Yeah, there we go.
It's fully operational and it's probably better than ever.
And we even have white rabbit link to a hydrogen measure.
So not only a 25 meter dish, but also a good clock.
And there's a lot of fun you can have with that.
But before we get to that, the thing we ran into on a practical side.
So this is all very practical.
I've heard a few talks here with not very nice frameworks and program and language.
This is much more just day-to-day stuff.
Is that we are there in the telescope.
We do something interesting following a spacecraft and deep space or doing something on the
astronomical side.
And there actually multiple things you want to do.
You want to save the data to disk.
You want to have a waterfall just to see it.
If there's RFI, maybe you want to do some online analysis already.
But it's really hard.
If you only have one SDR, most tools just capture the SDR and that's it.
And if you want to save an hour of data to this, then you're sit there, wait for an hour.
And you have no idea what is happening.
So we want to do multiple stuff at the same time with the same SDR.
So basically, I brought to you one the main application of what we're trying to do here is
to replace RFI letters with something digital.
So instead of doing it on the analog side, I have multiple SDRs on the same dish.
Let's see if we can do this on the digital side.
The other thing is ultimately the data storage and metadata.
So it happened me a few times that I did some measurements went home and then I happened
you was visiting and it says I kill one, I kill two, I kill three, I kill four,
and I know it anymore.
What exactly I've captured there.
So it would be really useful if we can store stuff and immediately have the data.
Where was the telescope pointing at?
Did we have the right pointing model?
Which frequency was it on et cetera, et cetera?
And not have to worry that yourself.
The other thing is keep the SDRs running.
So if you're going to do a very sensitive measurement, don't start your B210
five seconds before the measurement because it's going to heat up.
And the gain is going to change a lot.
So keep it running for all the time that you're actually in the telescope or wherever you are deployed.
This is not specifically to the granular telescope.
Also, if you keep the SDR running, the face between different measurements is going to be continuous.
Of course, it needs to be scriptical, scripted.
So we want to have something CLI-based, accurate timing.
And here I'm going to repeat something that Marcus said yesterday in the Knubolf is,
why are there not so many or so few SDRs with proper timing and timed commands?
Because that is what we need for all these things.
And everybody builds another 936 something clone and this feature is lacking.
They're all the same and they're all missing it.
And the other thing really important buffering.
So if you're writing to this, everything goes fine and certainly the disk sinks and your SDR starts dropping samples.
That of course should note them.
So this was the outline.
And what we settle for is use VRT.
So we feed the radio transport for streaming.
You use sigma for storage.
Now sigma for storage is already a given.
I think everybody is on that page already.
But VRT for streaming is somewhat less familiar.
So if we look at VRT, so this is Vita 49 radio transport.
And I took this from from their site.
And they critically describe it as a transport layer of protocol designed to promote interoperability.
I don't know what that means.
Either it's unteroperable or it's not, but how do you promote it?
And to be honest, they actually have somewhat of a point.
It's not really a protocol like implement this and you're compatible.
It's more like a framework.
It's a set of definitions of frames and fields and you can use them for all kinds of purposes.
But you might have different fields implemented.
So you're not necessarily compatible.
But it's a really great framework, I think, for doing exactly the things we need to do here.
There's several versions, which are additions, so to 49.2 has all kinds of extra features on top of 49.0.
We will actually be focusing on 49.0 here all the time.
So what is this?
If you're familiar, for example, with a ground station for geo-satellite, you have all kinds of receivers,
then you have a physical IF distribution to all kinds of panels with something most of the time in L-bent,
where you plug in your processors and they can duplicate and they can move things etc.
It's a really complicated system, but there's an analog interface to it.
So the modem side, let's say the digital side, analog interface interfaces to what comes from the dishes.
Now, of course, that's what we want to replace with a digital network.
So if we look at the received chain for any receiver, we have a lot of information that we want to capture.
So it starts with the antenna.
Where was the antenna pointing?
Then we have an analog signal, which goes to a tuner.
What was it tuned for? What was the gain? Was it locked?
What is the bandwidth?
On the ADC side, what sample rate was used? Was it overloaded?
Et cetera, et cetera. So we have all this information and here in the chain, you get your IF data.
And that's simply your IQ data.
Most cases, this is the data that gets stored, and maybe there's a timestamp and a frequency, and that's basically it.
This is all the stuff you want to capture, and also it can change.
It's not necessarily static, it can change.
So VRT actually merges those two things, and says you get one stream, and this stream has both your data and your IQ data, and it has your metadata.
And then there's that in a fairly nice way.
So just to have a look at the frame, this is the tedious part.
This is the data frame, so here goes your IQ that goes in here.
And then you have a header with some housekeeping, a little bit overkill and identify us with, okay, that's how it's defined.
And really important, there's a very fine timestamp in everything.
And there's some trailer where you can have some fields on what's everything locked and stuff like that.
So most of your data actually goes in here.
Now it's a big mistake if you take this frame and only use the IQ data.
So you ignore all the metadata and you just use Feta 49 as a framing for your data.
Because then you're throwing away all the good stuff, and then you think, well, what an over it.
It's not a nice frame, let's not use it.
So it's really the combination of this frame together with this metadata frame.
So here you have a similar one, also with timestamp.
But here you have all kinds of optional fields.
So you can put a sample right in here again.
The IF frequency is the bandwidth.
Everything you want to have here, and it's also extensible.
So this frame, you can send, for example, 10 times per second.
So whenever you get a stream, you wait a few milliseconds.
You get one of these frames, you know exactly what you're looking at, and you can interpret the IQ data that's coming.
You can even extend this.
So that's the whole idea.
You combine this metadata and this IQ data.
Now that sounds all perfect, and probably it sounds too good to be true, and there is lead a catch.
And that's this one.
It's not free.
How can you imagine this?
You need to pay for getting the standard.
There's no limitation on what you can do with it, but you just need to pay to get to the document.
And it's, it's watermarked when you get it really annoying.
I searched, I hoped I would give you a URL here, said,
Oh, but you can go to this URL and still get it.
No, you can't.
And I have a first in that I got from somebody who I'm not going to embarrass by giving it to you.
So this is silly.
I cannot do something about it.
This is really stupid.
But the good news is, we actually don't need this standard.
Because it's already implemented.
There's a nice library called Lip3RT from somebody called Emil Berg.
Does anybody know him?
Okay, I don't know him.
It's really nice to have.
It's really well written.
I really easy to use.
Well, document, et cetera.
Even if you don't do anything with the stuff I've done,
if you ever do something with Peter 49, this is the library you will need to.
You need to have.
So that's perfect.
So we don't need to read this whole standard.
We just use this library and it's API to do all the stuff we want.
So we don't need to care about the standard itself.
There's one caveat here in this library.
And the standard says, all the fields are big and the end.
This implementation says, I'm ignoring that.
So I just do whatever the house does.
That's not really nice because then it's not compatible anymore with between different platforms.
In the other hand, I only use xc86 or arm and it's a little Indian.
So it is compatible.
So what I did in the beginning was I made a fork of this with a branch that is big and the end.
So all the metadata is in big and the end.
The IQ data I leave in little Indian because I see no reason for all these platforms that we use to do
conversions all the time when it goes on to do wire.
In the meantime, I found out that Epic as the R manufacturer also forked this library and that same thing.
And we're actually in the description at the moment that we probably should collapse all three back to a mailbox original and make that one big and the end.
Because we're talking here about a few lines of code.
This is really nothing.
Anyhow, so this library exists.
So what we do here, we combine all of this and we're going to run this FIRT frames over zero MQ.
Now, almost any other implementation I've seen that there's anything between the 49 including DV.
I'll come to that.
Use it.
Use it over UDP, which seems obvious, but really why?
I mean, at the data rates we're working TCP works fine.
You have no packet loss and also it solves your buffer in problem.
Because CMQ, you can use as a huge buffer, which is also client specific, which works really well.
So we run this over zero MQ.
The other thing is with zero MQ, you can connect from server to client from client to server.
So you don't have this issue anymore that you have for UDP.
It's so much easier.
I've only found one case yet so far where UDP would have been better.
So what we do, we have a set of tools that is something to VRT, basically that's your SDR.
And in the other end, you have something that is VRT to something.
For example, to write us to sigma.
And then you have a pipe, which contains your IQ data, which is the majority of your frames.
And so once in a while you interleave it with a context frame.
That says, well, you're looking at this kind of band where it is the frequency, etc.
And we put our own extended context in here.
So this is the whole idea, and you can have multiple of these clients.
The way this is implemented, it's all very, very, very simple.
There's just an header library, nothing compiled, which you include.
That actually interfaces with lib3rt.
But the application itself is responsible for getting it on the CMQ stream.
So you just get a CMQ packet, you give it to this library.
It does all the parsing, and you get your data back.
It's really simple, and then you can start building a toolset on top of that.
And that is what we have done.
So a few specifics for what we have implemented.
Our data payload is always 16 bit complex.
A little Indian simply because that's the easiest one on the platforms that we use.
Every data packet is 10,000 samples, just fixed so that you always know,
if you get a packet, this is what I'm going to get.
So you don't need to know what you need to buffer for.
And we have extended context classes for pointing, which is the telescope,
to where is the telescope pointing, what were the settings for the pointing,
and what were we tracking?
For example, with Voyager, what we did earlier today,
there would be two frames in there, one is where the telescope pointing to,
and the other one is where it's Voyager.
Ideally, those are the same, but if they're not,
you really want to know that in your metadata.
Good, then we come to the SDR.
So we have a few platforms that we can, that we support right now.
And again, this is mostly based, includes GPIO support.
And you can actually use the GPIO on the SDR with your times commands.
So the time you have in your IQ stream,
and the time you have on the commands for your IO, are the same.
So you can do really fancy things with switching,
which I will show later how we use them.
So with full, I mean, you have external reference,
you have proper timing, everything.
And the only tool that actually do that is,
well, and I, and the RF space, cloud SDR from Peter,
and it's versions.
There's partial support, but that's more just for,
for showing stuff, or developing, is the air spy,
which actually works quite well.
And the SDR, just for creating some IQ.
Stuff, I have, but I've not released it,
because I'm not completely happy about it, is the Pluto,
which actually is works.
The lime SDR, because I simply never ever can get it right.
It always is off frequency.
It's not, it just never works.
This one, I really like, it's a really cheap clone
that this direct sampling.
You can run it at 200 megahertz.
Perfectly fine.
It's just not the SDR.
It's an ADC, but who cares?
And the epic sidekick, which I think is,
maybe the only one that is on the level of this one.
So that's what's currently on the SDR.
So then, we have these tools.
You have several of the SDRs.
And your metadata is injected here.
So there's a tool that actually sends from the control,
the tracking software and in-dwing a low,
into the stream, as well as the script that is the tracking.
And then you have all these tools here.
So you have, for example, Fiatty.
It's a new radio.
So if you want to play with a flow graph,
at the same moment that you're doing a measurement,
you just start a stool and you open a radio,
you get your data into a radio.
I have a sample flow chart to open it,
because I didn't want to build the block.
I wanted to have something that would work out of the box
with every deployment.
Fiatty to signal that is clear.
Fiatty spectrum, I'll show more about that,
but that was also the one I used for.
It's just a quick show to spectrum.
So for example, for Voyager.
And for some reason, I accidentally put a twice on the sheet.
But also, you can pipe this into or open this in other tools.
This is SDR plus plus.
So I made a plug in for that.
And you just start it.
And that automatically connects to the stream.
Set a frequency, and you have a nice waterfall.
We don't need to develop all everything ourselves.
Whatever is there, we just interface to it.
Here's an example from Dwinga Low.
This is our Pills Heart Pipeline.
So you click on the GUI, on the desktop,
and it starts this.
It starts the B210 software.
It runs Fiatty Pills Heart, which is in demo.
We have for live show and the Pills Heart.
But in the back, it also starts Fiatty to data,
which is a professional Pills Heart software.
And it does call all kinds of analysis.
So everybody from our volunteers will give us a tour
automatically saves all kinds of data,
which we can aggregate after a year,
and do very nice analysis on.
So here is already an application where you run two or three things
at the same time.
So you can also save the filter bank, which is a radio strongly format.
So Fiatty Spectrum is the tool,
where you can do easy stuff to make spectra.
So, because not everybody, for example, in cameras,
wants to do radio stuff.
Sometimes you just want to have a spectrum and do something
astronomically.
You don't want to go through all the hassle of figuring out
how to do it on the radio side.
So again, you start the SDR tool,
and you start the spectrum and you say,
okay, I want to have, in this case, five bins,
normally you would say 1000 or so.
Give me 1000 bins, one second,
start on the, on the integer second,
so I have nice easy timestamps,
and you just get a CSV file,
and you can open it in Excel.
I mean, for a lot of people,
that is what, what they need.
Or you open it in Python.
So this is, we export actually an ECSV format,
which is CSV with a little bit of metadata.
So here we do a scan over something called
from Wooden Cloud, which is discovered by,
actually somebody in the Dwinga file.
You open it.
You actually get the frequency and everything,
and just with a few commands,
you can make a nice plot.
So if you just want to focus on doing your radio,
or strong enough,
this is a room run at very long intervals,
like several minutes per per line,
and you have a few days of data and you plot it
and you can see how the spectrum is used.
So really simple stuff to get insight
in your spectrum.
So here's a list of some of the tools.
We have built this way.
We have VAT to filter bank,
which saves in filter bank,
which is in radio.
So let me format.
This is a fast radio burst,
captures with, with our tools basically.
So 200 megahertz of data,
and so this runs at 200 megahertz,
and this is like a single burst coming out of the universe,
somewhere.
VAT-Poser, that's our demo,
VAT-P to SIG-MF,
I cover it.
VAT to SDRF, that's from case Balsa,
where you can do satellite orbit fitting.
So you can run that in parallel,
really convenient,
a new radio, we cover it,
and then there's VAT tuner.
This one actually extracts a sub band.
So for example, you just start your SDR,
roughly at the right frequency,
and you say that to 10 megahertz,
and you say, okay,
now I want to have this 200 kilohertz out of that band.
It's a polyphase filter,
but it can also follow objects.
So for example, this is what I use for Voyager,
which I will have an example of.
So if your stream already says,
I'm following Voyager,
this is the frequency,
you can actually have this tuner,
follow the object,
and therefore the Doppler it.
Then there's a channelizer,
which is a polyphase filter bank,
that can extract all the sub bands.
But it can also do a non-minimal decimation.
So for example, if you have 20 megahertz,
you can split it in 10 times four megahertz,
or something like that.
So you get overlapping channels.
The nice thing is,
this also runs on a GPU.
So we can easily run this up to 100 megahertz
or something as split it in like 100,
one megahertz channels.
This is my favorite, Fiati to Void,
doesn't do anything.
It just connects and gets the stream.
But it's also the basis for writing new tools,
because somewhere in that tool,
it says do something with your IQ here.
So you don't need to start writing from scratch.
Next one is a correlator.
So basically it calculates the cross spectrum of two streams.
There's a four-worder that's for a local fan out.
So if you are at a remote site,
you pull the IQ data in once,
and then you locally distribute it again.
There's a control VRT,
which is the other direction.
So you can actually send commands to the SDR.
You can say,
change your gain, change your frequency to change the settings,
and there's play VRT,
which is for transmitting signals.
All of these I have examples of,
so that's more interesting to look at.
And as I said,
we don't need to reinvent the wheel.
We use set them,
we use SDR++.
I just wrote a plugin that connects to the stream.
You can run both of them at the same time,
no issue at all.
So really convenient for doing a lot of stuff at the same time.
So a few questions that I ask,
why not use new radio for all of these things?
Could you do that?
I guess you can.
And in some case,
that might be the better solution.
In some case, it's not.
This is not a new radio versus VRT tools.
This is really,
how do you combine and what is more useful.
Also,
I think new radio is a great client for actually this stuff.
Then there's something called D.V.
You might have heard of,
that's a normal implementation of Vida 49.
We looked at that,
but there were immediately all kinds of choices
that didn't work for us.
That's why we didn't use it.
Also, it runs over UDP.
So for us,
it was not the right choice,
but I'm still thinking about making a tool
that converts between the two,
because they're so close.
It runs at easily at two times 100 megahertz,
but we do it with X310.
We also tried 400 megahertz,
that's a little bit on the edge.
And unfortunately,
it's not really well documented,
which is my fault.
Good.
Now, we got the cool stuff.
What can we do with this?
So this is running at several places already.
So we've seen Bokum this morning.
Dring a low, of course.
Stock art is using it.
It's not a 25 meter addition,
Germany.
I've installed it at the ATA.
On the new radio server.
And this is a very simple dish in my backyard,
which I'll share later as well.
So,
but we've seen this morning was
the Voyager reception.
So in 2006,
they had done this in Bokum,
with a lot of equipment.
And of course, I mean, this was a year ago,
it was not so simple.
But in between, there has been nothing.
So in between last year and 2006,
they have not seen Voyager.
And with these tools,
it's actually relatively easy.
And then we did it this morning again here, live.
So this is a good example on what we actually run.
So here,
we have to be to 10, which I use in all my examples.
We have Pursa P to Vrt.
We have the Dringler Telescope control
that inserts the tracking data,
or actually the data that this is pointing.
We have a tracking script,
which takes high-scurrenals as the input.
It tells the control where the track.
But it also inserts the same data
into the IQ stream.
Then we get the zero MQ stream,
which is in this case.
One megahertz,
it's overkill,
why would you not set it to that.
And then we have a tuner, which is tracking.
So this one is following the Voyager signal.
So it deducts the Voyager in a continuous way.
So every sample gets its own correction.
It's not doing like one hertz steps every second or something like that.
It's really simple by simple.
It's continuous.
And then you get a stream,
which is only 10 kilohertz,
and that's why you run into Vrt's spectrum,
and you see the peak.
The other one, we run one,
because we also want to save data,
but you don't want to dedopler the data.
You want to have the original data, of course.
So we run another tuner,
which we set non-thracking.
So that one just saved 50 kilohertz of the original data,
because it doesn't make any sense to save one megahertz
for a CW of one hertz.
And that we save to sigma f.
So this is really simple setup,
but this is how we track Voyager.
And you can run that on your laptop, of course.
It doesn't take any CPU.
Good. Now you might think,
I don't have a 25 meter dish.
Why is this important to me?
You can easily do this on a 1.5 meter dish.
Of course, not with Voyager,
but this is a set of really simple dish.
It's not optimized in any way.
And I easily do,
do you know,
at Jupiter, which is 620 million kilometers away.
And this is Beppe Colombo.
This is actually the mercury fly by,
just on a 1.5 meter dish.
So you really don't need fancy stuff to do.
If you also don't need to beat to 10,
you can do this with an air supply.
It just works.
Good.
Now that was about 25 meter dish,
but now suppose you have two 25 meter dishes.
And now the timing gets into the picture,
because if we're the only dish that timing is somewhat less relevant,
with two dishes, it starts metering.
So we have exactly the same setup.
And this is important,
because even to beat to 10,
it's not accurate in everything.
If you set it to a certain frequency,
it has a few million Hertz offset.
There might be over that.
There are offsets in timing, etc.
But there are exactly the same.
So they are reproducible.
As long as you do the same setup on both sides,
you get the same offset.
So they cancel out.
It's really important to set the master clock rate of these things,
the same, because a lot of it depends on that.
Then a new feature here is,
we can also transmit with the B210.
So we have a tool,
which we can transmit files.
So on one side, which is Ringelow, which runs metafile,
we bounce it off the moon, basically.
And then on both sides, we receive it,
and we save it into a sigma file.
So we have all the metadata,
and we have a nicely synchronized set of data.
Now we can do that on the moon.
Later on, we can also see we can try this on Venus.
So the physical setup looks like this.
We have the B210 on the output.
We have a small amplifier, which has an output of one watt,
because we need to drive the amplifier here to 120 watts,
and it's one watt input.
And this is the sequencer for the Ringelow telescope.
So this is all the switching of the relays,
and the LNA is an everything to make sure you don't destroy anything.
When you start transmitting.
And we control that from the B210.
So based on the Vita 49 stream,
we send commands that actually do the relays switching.
So it tells you just before you're going to transmit,
switch the relays.
And it's always in sync with your transmission,
because it's using the same timestamps.
And then over here, we have the relay and the feed.
In the end, we only get 70 watt or so out of the feed.
Keep that in mind when you're going to see the pictures.
So here you see basically what happens?
At one second, we start transmitting.
And you see just before one second,
you see the switch being made.
Now the protection relay goes on.
We are switched the receiver to a 50-on resistor,
which is hotter than the sky we were looking at.
So our noise actually goes up when we terminate the LNA.
Here we transmit, of course, that gives a complete clipping of the signal.
So you see all kinds of stuff.
Ignore that.
This is just a CW.
Here we wait a little bit before we switch back.
And here we go into the receiver mode.
And here you see the CW being reflected from the Moon.
You already see this as like offset and frequency.
So there's a bit of Doppler from the Moon.
But this basically is the whole flow for transmitting and receive.
Okay, I'm going to not go to cover the details here.
The Moon is not a point source.
So you have different speeds to different parts of the Moon,
which gives different slightly different Dopplers.
And that's what we're going to use for our analysis.
So we sent a CW, so a pure tone.
But we get back, has some spreading in it.
So we sent basically a single tone.
And we get something in this case, which is spread around nine hertz.
That's basically of this pseudo rotation of the Moon.
We can actually predict it.
And I might even have copied this code from you.
So you can predict how this Doppler is going to be spread over the Moon.
And you will see this, this widening.
With that, you can do something called Delay Doppler mapping.
Because basically we have two axes now.
We have the Delay, because this is the front of the Moon.
So our first echo will come from the front.
Our later echoes will come from deeper parts of the Moon.
And we have the Doppler.
There's only one problem, there's an ambiguity.
So where the Doppler and the Delay cross each other,
there are two points that map to the same Delay Doppler.
And we're going to see that later on.
Basically, the two hemispheres will fall over each other.
We have not invented this.
This was done in the sixties.
I think this one was with RECBO or Hillstone.
So there they used a pulse, because they couldn't do the fancy stuff.
We're going to do.
But you already see the Delay Doppler map coming back.
So we do this as well with these scripts.
So we just had this play command.
We play a sigma file, which is this one.
Completely overloads the front end.
And we receive an echo here.
And this echo we're going to compress the single point.
And now we can actually measure the depth of the Moon.
So here we, this is the front of the Moon.
So you see the peak.
And then you see it slightly, slightly,
dying out deeper in the Moon.
And this is where this is basically the depth of the Moon.
So what we use, and again, I'm not going into detail here,
because the simply isn't the time for that.
We use it of two sequences.
If you want to learn more of those, go to Danny's block.
He wrote some nice details on an analysis on how this works.
If I have to summarize it in one line,
it's basically an alias chirp.
And if you look at the waveform, it looks like a chirp,
but also you see there are actually more chirps at the same time.
Kind of.
But they have very nice outer correlation properties that we're going to use.
And you can make them extremely long, indefinitely long.
Doesn't ambiguity, which I will skip now as well.
So we immediately go to the result.
So we bounce this z of two of the Moon.
And this is what we get back.
So this is 60 seconds.
So obviously this is between doing a low and stalker.
Because the echo from the Moon comes back in like two, two and a half seconds.
So we transmit for 60 seconds, stalker receives for 60 seconds.
And because of all of the nice synchronization between the SDRs,
together with the good clocks on both sides,
we get a perfect match with what we expect.
So our frequency is at zero, where we expect it,
and then you see the delay going into the Moon.
We can see the full depth of the Moon actually show along up.
Every point here in this graph, every small point,
is a correlation of the transmitted signal with the full received signal
for a certain delay and offset.
And then we look on how strong it is.
I'm not the first one to do this in Dwingelo, even.
This is from Peter Cherich, a long time ago,
who did the same thing.
But he actually managed to do it through the audio signal
of the radio amateur equipment.
So we only had a few kilohertz to do this with unlocked equipment.
And he did, I think, a lot of these things on top of each other.
And it's amazing that he got to hook out a shape out of it.
This is a real achievement.
And in his article, he writes a list of all the things
that could be done better.
And that's exactly the things we have done now.
So thanks for that.
So we have different frequencies.
We normally do this on 23 centimeters,
because we have the most power.
And we have a good Doppler resolution.
We can do it at 70 centimeters, but the wavelength is longer.
So you're like a resolution in your Doppler.
And 30 centimeters, we don't have enough power to properly do this.
You also see some asymmetry here, which is interesting,
because we're not eliminating illuminating the full moon anymore
at this point.
And yeah, we do all this work with 23 centimeters.
Now, there's another interesting one.
We get two echoes back, because stock art has two proliferation.
So they have linear polarization, horizontal vertical.
And from that, we can recreate our LHCP and RHCP.
We transmit RHCP.
So what we receive back from the moon, but we expect is LHCP.
That's the normal echo.
But the moon is not a perfect sphere.
So we also receive, like I said, the wrong echo.
And it's interesting, as that one has more detail.
Because those are basically the features you see on the main.
So this one is stronger.
That one is more interesting.
Let me see how I'm doing on time.
If we look at the power of these,
obviously, the LHCP is much stronger.
The RHCP has less power, but has more features.
This is nice.
All these kinds of things you can compare from articles from the 60s.
They were doing so many of these experiments then.
And it's nice to see that you get the same plots, but I will not go and eat.
Okay, we skip to the results.
So this is basically the screen is a little over-illiminated,
but this is what we achieved.
This is 10 times 30 seconds stacked on top of each other.
And here the timing becomes really critical,
because you're talking minutes that you need to keep everything coherent.
This is the LHCP.
If I switch to the RHCP, you will see it's roughly the same.
Here you see a bit more detail.
I'm not a switch back and forth.
You see one has more power, and the other one has more detail.
But both are actually interesting.
There's one thing though.
This might look like a picture of the moon, but it isn't.
I basically cheat a little bit by giving it the right aspect ratio
to make you think it's the moon, but you have the two hemispheres overlapping here.
So this is the front of the moon, and then you have the two hemispheres.
If we basically recreate the map, so this is based on the map from the moon,
we can see that all these craters are on the right place in our reception.
But if you would look at the moon, you would not see this.
This is actually two halves of the moon, and then fold it on top of each other.
To make it more insightful, this is basically what is happening.
So the next step is we need to have multiple measurements with different orientation,
and then we can start removing those two.
But that's still on the two loveliest.
I have one more interesting one. This is my favorite.
This is work. Yeah.
I can look at this for hours.
Basically, I was showing pictures which were like 30 or 60 seconds overlay.
This is real time. So this is playing at real time on where on the moon,
the echo is coming from.
And you see that you get destructive and constructive interference.
So you see these canals that's basically where the waves are destructive.
And the yellow places are the ones where you get the reflection from.
And you see because the geometry between us and the moon is moving,
you actually see it changing all the time.
I find this amazing to see this in real time.
Twenty-three centimeters.
Yeah.
Okay.
Next one. So I've already shown. So this was the moon.
That's easy because you get a lot of power back.
The next one is Venus.
Now we try to do the same thing.
So Tom and Jan made this one.
We had a picture of it, but he automated the animation.
What you see here in the middle is Earth.
The yellow one is the Sun. The white one is Venus.
And you see that Venus is in between us and the Sun every one year and seven months.
And that's when it's very close to us.
And we need that because the radar equation has the distance to the fourth power,
which means you always lose.
There's just no way you can compete with that.
So we really need it over here.
At the same time, this is also the moment it's between us and the Sun.
So this is pointing at Venus and you see how close to the Sun it is.
It works, but if your sight loops are just in the Sun,
you will actually notice that.
So we wanted to try the same thing as we did with the Moon.
So basically, this is the same setup.
The only thing we changed is that instead of the amplifier we had here,
we put a 1 kilowatt amplifier in the front end.
So right at the feet in the center, in the focus of the, of the Dwingelow dish.
That works because then you get really 1 kilowatt of power.
It has some issues that I will show later.
So here we're installing it.
We have a lift, so you can go up.
You can do work, you can take the whole focus box out of it,
and do the work on the ground, and then put it back in.
Here you actually see the feet going back into the, into the box.
Over here you see the 1 kilowatt amplifier.
And this is going to be put into that hole.
And you can already imagine that there will be a lot of heat coming from this.
That there's not going anywhere.
That's what's indeed the issue.
I'm going to skip.
I have still how many minutes do I have?
Okay.
Then I will just.
So we're a little bit looking with Venus in the sense that the huge Doppler we get from the moon is much smaller on Venus.
Also because of the retro gate,
we have a rotation of Venus.
So while it's coming towards us,
it's rotating in the other direction, which cancels the Doppler spread a bit.
So most of the energy we get back from Venus is actually in a very small bandwidth around one herd.
So even half of the power are so we get back in one herd,
which means that we have a chance of doing this.
So we had a whole list of things we're going to send to Venus,
and we start with 4 CWUs, and then we had a whole set of interesting set of two sequences, etc.
And after the 4 CWUs, the set of field.
And we only had one window of two hours to do this,
because we had a permission to send with one kilomatt kilowatt in a bandwidth,
which is very close to the Galileo, etc.
So we, yeah, it filled and we couldn't redo it.
Skipping to the results.
So we did see an echo, luckily.
So we have four transmissions, four receptions,
because we were both receiving ourselves, five minutes later,
and Stockat was receiving.
Stockat reception was much better.
Maybe also because we were heating up a little bit at that moment.
But still, we see the CW coming back,
and if we summarise all of them,
we actually get a very nice as an R on the return.
And again, I'm going to refer to Danny's blog,
because he read it the whole analysis,
with a better match filter.
So if he got even higher as an R's out of it, then we did.
And I will skip this one as well.
Oh, yeah, this was the result.
So the transistors, these sold at themselves,
they simply, some components,
even some of the capacitors,
even to simply fell off the whole thing.
But it's all repaired now.
Okay, last topic, very quickly,
simply because it's also fun and related to timing.
Very long baseline in the Fermatry has been done since 1976,
in the vanilla telescope.
That's the nice thing.
Everything you do there has been done before.
And there's always history to it.
For the white rabbit people, this is an old rebedium clock,
with a battery.
So instead of transferring the time over a white rabbit,
you basically carry your clock with your battery.
That's the alternative.
Paul has done this and presented here in 2018,
doing interferometry.
So getting fringes between the vanilla telescope together with Joe Robank,
and Resterbork, but it can be a radio of flow graph
that created videos if I'm not correct.
And then using the GIVE correlator.
This is professional stuff, of course, with the other telescopes.
It's ice-hawry.
For you, it was hobby.
I also got a note from the person actually in the photo
on this experiment.
The first fringes in the vanilla was on 3C73.
That's the first one they have ever tried this on.
So now we have, again, these tools.
So I'm doing everything with the tools that I have described before.
And we do this with stockers.
Now it's basically the same as the EME setup.
The only difference is we're not transmitting and correlating
the reception with the transmission.
Now we're simply correlating a quasar.
So we're basically a noise source in this guy.
But we need to tell the scope.
So again, we get two files.
Everything is synchronized simply by design.
But we can also do this life.
Because this is streaming data.
We can stream data from one telescope to the other,
run this VAT correlate.
And at the moment we point, you live.
See, actually, the correlation between the two streams.
There's a script that actually calculates the whole geometry
and updates for that.
So with that, we can actually detect very far sources.
So this is a quasar, basically the nucleus of a black hole.
Let's say a black hole very far away.
This is a quasar with a red shift of five-foot-four,
which means we're looking back in time here, 12 billion years.
So this radio wave has been traveling for more than 90% of the lifetime of the universe
before we capture it with the 25 meters of this.
And we do it with two dishes.
And we look at the signals we put them on top of each other
and they actually correlating.
So they are the same.
This is extremely far.
It's mind-boggling how far you get with some such dishes.
Another one, this was a discovery for me,
is that, of course, we can do it with two 25 meter dishes.
That's not hard.
So I put my own one-and-a-half meter dish in the equation again.
I can easily do this between a low and my one-and-a-half meter dish
or between stockers and my one-and-a-half meter dish.
Because as an hour of the correlation depends on the geometric mean of the dishes.
So if you have one really big dish, the old one can be really small.
So you still have basically a big dish if you calculate the mean of those.
So even with a small dish, you can do interferometry or actually time transfer
of all the things.
I think this opens a lot of possibilities with relatively simple hardware.
I must admit that I have a good clock.
That's the other part of the equation.
Another one over very long distance, so we can also do this
between being a low and the alan telescope array.
Well, but the single dish.
That's a huge baseline.
That's 78,000 kilometers.
And it correlates fine.
The phase is not completely stable, but this is five minutes.
So there's still not bad.
Okay, we're almost there.
Last one, and this is actually the bridge to the next talk.
We're doing this all on the full data.
So we have 12 bits of data and we correlate that.
But we can also do this on one bit data.
So we just off the 12 bits IQ data.
We only keep the sign basically.
Especially if I do this between the two telescopes,
so the Dwingalo and Marwanda and half meter this,
I still have something like 76% of the as an R.
Which is quite good.
Interestingly, that's a different number than Jean-Michel is going to show
in this presentation.
And we'll leave it at that.
So this is from a project to do with your small home.
And we can definitely extend this.
Okay, there was very quick.
There was a lot to cover.
And there was a lot I wanted to show you.
Big thanks to everybody who helped Tomoyon,
and case who contributed to the VRT code.
Paul, for all the time and frequency stuff that is key for all of this.
Otherwise, we couldn't do it.
Wolfgang from Stockard's Peter from Abovecom.
And of course, cameras is a big team of like 60 people
who all keep the telescope running.
There's no way you can do that on your own.
And the other thing is, if anybody is interested in cameras,
talk to me, talk to Paul, we're here,
and it's a volunteer organization, so you can join us.
Okay, that was it for now.
Everything I've shown is online, data is online.
Everything is available.
Yes.
We have looked at that, but you wouldn't need...
It's a feedback loop, it's too slow.
We didn't, we've tried it, we've not managed to do anything.
But it's a good question.
Yes.
Actually, it built a such a way that you can merge any control data into that.
But you have to define either your own format,
or use one of our own formats, but it's completely generic.
So I write this clip basically for every site that injects the control data into the,
which is separated from the tools.