 Okay, so Osmoor FDS or the RF Delay Simulator because that's the best name I could come up with So wait, it's not exactly Okay, that's better So when the What the name says pretty much what it does, right? It simulates an RF Delay, which means you Have an RF port which takes an input signal and it transmits that same input signal on the output port some time later hopefully a deterministic time later At the moment it's just Simple delay, but it could be you know extended to actually simulate multipath of things like that as the need arises for it so why Did I do that? Well the goal was to you know integrate with the GSM Tester at sysmo com which has a you know different hardware connected and stuff like that to To test it and and mainly the this particular piece would be to you know experiment with the timing advance At the lowest layer possible so that you test the entire stack because you know with virtual fire and stuff like that You can simulate the timing advance at different layers of the protocol and things like that, but here it's to really have it on the On the Yeah, exactly the real device, you know you And so yeah, and our alt was looking for a solution for that for for sysmo com and And the Pluto was seemed like a good solution other option that were configured considered where RF over fiber with you know long spools of fibers or long RF cable stuff like that So there's a little more software defined So that the target device is the Adam Pluto Which is you know, basically a zinc connected to an ADI 9361 Why this device when mostly we have plenty of them around and We need to find something useful to use them for right, so That that seemed like a good match The the bull system to generate custom images and custom applications from ADI actually works Astronomically well like you if you follow the instruction You you will get a working image out of the box. It it yeah, it works What's a bit annoying about those images loaded on on there is that there is no provision for any kind of persistence Which mean that every time you plug it and unplug it and it reboots Everything will be lost. There is no Overlay for persistence or anything like that at least that I could find Which is a bit annoying because the FPGA image is actually needed on boot And which means that every time you want to change the FPGA image You actually need to rebuild and reflash and completely a new image the the zinc itself allows changing the FPGA configuration on The fly but something somewhere in the ADI's logic doesn't like that And the Linux side will work fine But you won't be able to talk to any of the SDR part which you know kind of defeats the point in this application Yeah, other minor issue is that by default they use R&D is for the so under when you plug that on your laptop you get a CDC You know console basically you also get a network device and they use R&D is I patched the image use ECM Which is more standard and mostly because I didn't have the driver for an R&D is and I didn't want to build them I had the ECM one Same thing SSH keys because again everything is lost that reboots if you want to add your own SSH key You actually have to rebuild an entire image with that Which means that it's very possible that the pre-built image that's distributed on the website actually comes with my SSH key As allowed to look in as root on the device Beware of that so IO so IO is the you know framework for That's been made by ADI to interface with various things. It wasn't especially designed with SDR in mind It was you know all industrial sansos and that kind of stuff and it's been kind of forced into being used for SDR in this application and So when you log in on the Linux running on the zinc you get an IO device and that's all you're supposed to talk to the SDR parts I try to implement the loop back and and everything using purely IO because IO gives you those buffer objects and so the hope was that you'd be able to you know Get a buffer from the Eric's and then feed it to the takes So that the zinc wouldn't have any actual work to do except shuffling buffer around There's a variety of ways for which I didn't work The first thing is that the IO buffer is really just it's an opaque wrapper You have no idea what's inside and it doesn't actually there is no mapping between There's no constant mapping between a IO buffer object and the physical buffer they they will Switch the the physical buffer inside the same you know buffer And so you can't just give them And consider them as mapping to a constant area in memory The other problem is that that opaque wrapper is actually tied to a specific IO channel So you can't use an IO buffer that you get for Eric's and send it to takes that just doesn't work that way and I Tried meddling around in the inside of IO, but couldn't get anything to work And that wouldn't have done any good for the two reasons that follow is that IO has no timestamp whatsoever so You can't tell him to transmit buffer at a Defined time or you can't get the time at which you received an Eric's buffer You also have absolutely no way to start Eric's and takes pass at the same time Because there is no time command or thing like that which mean depending on When the Linux would issue the actual rights to the memory map TIO to start and stop the DMAs engine The loopback delay of that error of delay simulator was basically random on boot. It would be more or less constant But random and you couldn't choose it which is you know really not good It would be a multiple of the buffer size, but that doesn't have you that much, right? The other problem is there is no feedback on over and under floor Which mean if at for any reason or anything you miss a buffer on a thing well that random delay would actually vary over time Which is really not good at all So I kind of dropped the idea of using IO for for that Other fun things in IO is the naming of the you know You have you have IO devices and inside those devices you have channels And the mapping of what does what is really not that obvious? I mean if you see you know CF 89 361 LPC That's the receive path You know there isn't Eric's absolutely nowhere in that name and then CF 89 361 dash DDS dash core dash LPC That's the transmit path in why and Somewhere buried in the documentation you can find what it what does what but when you first Go into it. It's really not obvious Actually documented what does what in if you look in the source code of the control application I actually documented what names maps to what in case you're confused. Yeah Of course, I still need to use IO because I need to actually start up the device stuff like that And I you know I don't want to reinvent the wheel and and so I just reuse IO, but it just Sets up the frequency to gain and and configure my custom logic So the custom logic well since I can't do it in IO I decide to do it directly in the FPGA, right? because it's redo You know the right right way to do it anyway Again the FPGA code for media is actually pretty good It might be a little too generic for my taste you can see it's an you know It's an example code that they distribute So that people can take it and integrate it in their own application But that that means that the very low code is actually supports the chip being interfaced using LVDS or using CMOS or all those options which are actually not used and did on on the On the Pluto because well, it's depends on your PCB layout. Obviously you can't change it dynamically So there's a bit too much option So sometimes it can be hard to understand or see exactly what's used and what's not but it's it's fairly well structured And didn't take too much time to to see What does what and and that part is actually fairly well documented The modification is like super simple Basically, I just tap into the RX pass you have a blog that handles all the physical interface You know like the CMOS IO the sampling of the DDA edge and all that kind of stuff and that feeds that to packetizer and and things that Sends it over to the zinc. I just tap the data at that point feed it to a variable delay line Which is really just a circular buffer where the read pointer and the right pointer Is the are at a fixed configurable offset from one another and that offset is configured by the zinc and that fixes your delay basically and I directly injected into the the transmit path so transmit pass it can act as the Normal usual way it would normally work so you can you still use your Pluto as a normal Pluto with no issue but if you Tuckle the right bit in the right configure register instead of just transmitting with the DMA sends it will actually take the signal it received Multiply it by a constant so you can vary its amplitude and add it to the signal that you asked to transmit and send it off I did an addition Because that way if in addition to the loop back you want to add say goes and goes and noise to test You know the SNR response stuff like that. You can actually do it and IO actually has a nice feature I guess that you can just give it One or a set of buffered and then tell them to play in a loop And so you just set that up at the beginning and it will just auto-repeat basically So yeah, that's a very simple FBG modification and that could easily be extended I mean at the moment it's really just an addition, but if you put an FIR with complex tabs you could have a channel Once to be one step closer to a channel simulator and if you add multiple of those in parallel you can have You know multi path with different length with you know fairly easy Modification you can just xylings as free fire compilers and stuff like that. So yeah If anybody if anybody needs that it's it's not too hard to do The control software well, it really doesn't do much it just really just sets the frequency gains and that kind of stuff Trans it does continuous Eric's, but it does nothing with the data just drops it a Transmit zero actually turns out it's not even needed Yeah, you don't have once you've started the Eric's it will actually continue and if you Start the ticks it will end the flow or overflow if you don't actually shuffle the buffer, but The FBG logic will continue to work including the loop back Which means that if you actually kill that application The loop back actually continues It doesn't shut down on song Which I consider it a feature, but maybe you can see it as above depends on the way you see things Whatever And yeah, it was not that many often Something else that was developed and that's kind of interesting and it was developed at the same time but it's kind of unrelated to RFDS itself, but it's just in the same repo is the UHD pinger because I needed to test the I mean what I developed I needed to I needed a way to actually test it, right? I Originally, I plan to use my signal generator and the E4406 And that's when I realized that my E4403 is broken at the moment and I haven't taken the time to fix it yet So I developed that instead And basically it measures the latency using an UHD device So it just sends periodically a burst of a BPSK modulated data out of the takes port and using timestamp It does a synchronized RX and then it tries to find okay How many samples after I ordered the transmit do I get the pulse back? and So using the transmit and receive on different frequency I was able to test the Osmoor FDS That you know, I got the echo at the right time and that if I told The delay simulator to simulate a 100 microsecond delay I actually got the data a hundred microsecond later that I tell him that if I tell it to simulate a zero sample delay for instance But it can also be used to just to test the intrinsic latency of a UHD device If you look in the Osmo theory, there's a bunch of magic values in there that represent the kind of the latency of the FPGA image of the The B200 because you know, it has digital signal processing blocks CIC all band filters CICs I already said I think yeah, whatever. I meant the codec. Yeah And all those magic values they change depending on the sample rate on the the master clock rate that you configure and that kind of stuff But in Osmo theory, it's very important because you need to you know Know when Ericsson takes are aligned and so you could actually use that to to measure those value and check that they actually make sense Currently, I mean it was done really quickly because it was just a tool to test Osmoor FDS Improvements would be FFT based correlation of the one. I just do a naive correlation of just you know summing in adding At different offsets, but that takes time if you use an FFT you can go much faster Or so currently I just generate a random bit stream from you dev random. I think and BPSK modulated Which works fine But if you wanted a sharper peak in the correlation, you could use codes that have good known auto correlation properties You know like gold codes out of two that kind of you know things that are used for trading sequences So that's an example of running the finger and you see you just configure here At a given frequency and eventually you get yeah an echo and it tells you how many samples afterwards It was it was received The other values are just the amplitude. I think yeah the the amplitude and the threshold It can also detect multiple peaks if there are several peaks that are strong enough so a couple of resources while you have the the project which has the the actual documentation of Or to run it or to build it and also some prebuilt image that you can just flash. Yeah Oh, yeah, because I was testing over the hair Oh, yeah, so the question is why is the transmit frequency different from the Eric's one It's because this particular test I was testing over the air not with cables and so I can't test I mean that there would have been a conflict if I if I tell the or smaller of DS to receive and transmit With a delayed version it would create a loop, right? I mean with cables you can transmit and receive on the same frequency the cross talk is Small enough, but when you're over the air It would kind of create a sort of a I don't know like a loss and effect in in RF or something. I just yeah You see or because I mean if you tell if you tell him Osmo or FDS to transmit the signal one microseconds later back And you're over the air it will When it transmitted once one microsecond later it will again we receive it and then we retransmit it one microsecond later And so that creates a loop that yeah exactly and Echo produce echo except RFDS actually Amplifies the signal as well. So yeah, you just end up saturating itself basically So yeah, the other project page with a prebuilt image how to build it and how to run it the actual code if you want to you know, rebuild it yourself and This is the link that to the documentation to the Pluto itself. It's the wiki from analog which has some decent information about the Pluto and How to build the image and that kind of stuff And yeah, thank you for thank you to see small come to a sponsor the work on the on that project and And and to another device for actually providing us with the Pluto's and that's it if anybody has any questions regarding the Pluto and the the loop. Is there some space left in the FPGA for for example for doing some complex multiplication and modulation of the signal to generate Yes, there's plenty of space left in the FPGA for doing a lot of things. I mean, I don't I think there is like Maybe like 5% of the Complex blocks the DSP blocks used and and also very few block rams There's a significant part of the logic elements used in the FPGA but the block rams and the DSP blocks There's plenty of them to go around. So yeah If you want to do complex multiplication or an FIR filter with complex tabs and that kind of stuff plenty of space for that Yeah, well, I'll just repeat it. Just say it and I will repeat it in the microphone Yes, so the question is about the UHD finger because in the in the MS implementation by Piotr there is something similar and Yes, the UHD finger is also it's in the Osmo or FDS repository in the tools directory or something. So it's there in that repo Yeah Yes, so the question is how much delay can be stimulated I honestly can't remember But it was very significant it was it was more than a more than a Multiple time more than a GSM frame. I remember that and I didn't use All the block rams that I could have used I left a ton of them free so yeah, it's it's definitely Significant as you say it depends on the sample rate, but I was kind of working on the Like a one or two mega samples per second because it was for GSM and that's that's way enough But yeah, as I said the the default design of the Of the ADI doesn't actually use a significant amount of block rams For some yeah, I can't for some reason my my browser doesn't display but whatever So most of the block it's a zinc 7010 and yeah, I'm pretty sure like 90% of the block ram are free So, you know look up the specs and do the math for Yes, so the the question is about the sample rate and yes because as you say Everything happens in the FPGA. You're not limited either by the bandwidth of the USB or Even by the processing power of the zinc or anything like that So yeah, you can I I think you can run it up to 30.72 mega samples per second in the way they're wired in the The Pluto basically the maximum sample rate of the chip is 60 or something, but depending on how they wired the FPGA interface to the FP to the ADI The ADI to the FPGA The interface can only run at a given clock frequency and you need to have transmitted and receive enabled of course And so I think the limit is 30.32 But yeah, I mean to simulate LT at 10 megahertz bandwidth would be no issue. Of course you get you know less delay because you need more samples, but Should be more than enough to Yeah I mean you you can dynamically configure the delay, but Obviously at the point where you change it you have a discontinuity, right? It's not gonna do like fractional interpolation or progressively change the delay You can progressively change it one sample at a time. I guess but you will have a small Non-linearity at the time where you where you change it whether I guess if you oversample enough It shouldn't destroy the signal too much if you change it Progressively enough basically, but the the core definitely Supports changing the delay on the fly while everything is running Now not at the moment it would it would be fairly easy to To simulate multi path because you can just instantiate a second block and a second adder and have a both configurable for instance Sorry, yes, yeah, you could you could Yeah, as I said, oh, yeah, I made a mistake It's it should it should say codec here and not see I see because see I see wouldn't help to add a frequency error But yeah, you could you could add a complex multiplier with a codec to Simulate a frequency error and simulate Doppler. Yeah There's a bunch of as I said because most of the DSP blocks are free and block ramps are free too there's lots of room for extension if anybody wants to to do that or needs it Okay, thank you