Open Research Institute Weekly Reports, 7 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: ORI FPGA Standup 7 June 2022

Description

Uplink progress, Remote Lab South plans, and "can't avoid Petalinux" with the encoder side.

A

Welcome to the june 7 2022 meeting for the fpga team at open research institute, it's a stand-up meeting and what we do is we talk about what we've done over the past week and what we are doing over the next week and if we need any resources, if we have any roadblocks and so first off what I'll do is I'll turn it over to you paul.

A

So you can tell us about um any recent remote lab work and maybe talk about the potential for the a blank, simulator and uplink um work to eventually move to fpga.

B

Okay, I'm paul kb5mu for anybody who hasn't already seen my face on these videos. Nothing to report from that remote lab everything seems to be working haven't had a any major events.

B

There we've been working on this notion of an uplink simulator which generates multiple channels of our narrow band, uplinks, our fdma uplinks and with a certain amount of versatility, so that we can test a multi-channel receiver and I got reported on that last week we reached a certain point where we were able to do that with the m17 modulation and then said: okay, that's far enough with m17 and I've been working with michelle to understand, what's necessary to switch this over to a higher data rate link, which will be something new uh that we've sketched out that have not ever specked out in great detail.

B

So we're going to do that at least on some temporary basis, make some uh quick and possibly dirty assumptions and just go forward and get some kind of higher speed down. Uplink coded I'll mean coding, both the transmitter and a receiver for it in order to to do testing and we're using as a basis the c plus plus implementation that m17 provided at least that's the current path.

B

We've gone through that implementation in some detail together and understand how it's put together, we think and we're going to start taking it apart and putting it back together with a higher data rate. So we start out with 16 kbit opus as our high quality voice, codec and hopefully design it such a way that the data rates can be moved around dynamically and won't require a revamp of the code every single time, that's sort of a stretch goal here.

B

Just we just want to get it out at 16 kilobits and that will take some additional work because everything's hard-coded to particular numerology for m17. So um that's the the process that we're we're going through now and there'll be more work ahead before that has anything very much demonstratable.

B

That's where it's at and hopefully it'll be somewhere a little further along next week.

A

Cool okay, thank you, yeah! I'm hoping that um in between this set of work for the uplink, um and there is an existing implementation for for m17, this exact same body of work from the same author uh on pink pynq, the which is a zinc processor. So we we have a fork of that in the repo.

A

So between those two things, I think that we can get a a receiver on the on the payload or what we call the spacecraft on the zc706 um that we can use all of this to to create a receiver and then in between receiving the uplink and transmitting the downlink with the existing encoder. There's a lot of work there too, a straightforward multiplexing is probably where to start, but we're already talking about quality service and things like that and the in the documents and in the list and on slack.

A

So that's that's where it's going and uh that's where it's or that's, where it's been, that's what the current uh word is up to now and and then the the plans that we're talking about are where it's going. So. Thank you very much. This is a pretty exciting stuff cool.

C

A

Hey james, uh you have the war.

C

Thank you michelle uh not too much to report from remote lab south.

C

Here we had a few storms, but nothing major in the way we're looking on doing a bit of upgrades in regards to our basic infrastructure, with decisions we currently have, mostly in the way of we've, got a new uh apc that we're going to have chub going to so there's going to be some down time in the near future, when we do that and uh in regards to actually getting the more proper lab, set up, we're getting more cleaned up and debarn and getting things ready more over there getting some cleaning done, but other than that, nothing too major important, no major roadblocks or resources.

C

We really need.

A

Oh wow, okay! Well, that's a good, really good progress, and- and thank you let us know if there's anything that you need and uh if any funding is required.

C

We definitely shall thank.

A

You, okay cool all right now on shul he's he's not able to join today, um but he's been very helpful in a particular aspect.

A

So what we've been doing is for the zc706, which is a 7000 series, zinc based board, which has an adrv 9371 rfo ic from analog devices that we're using for for designing all this stuff and what we've struggled with is integrating the encoder uh ddbs2 encoder that we have and getting it tested over the air or demonstrated over the air and yes, the encoder works and performs well on bit, matched from from guinea, radio and such but but mastering the being able to control it.

A

Very you know, competently and well uh from the fpga has has been really hard, and so what we've been focusing on is getting this working and and more people learning how to do it, and so on has a number of steps.

A

um The mistake that I was making in trying to get this working here in remote labs west was just approaching it from a strictly hdl point of view and taking the code base and trying to to use the integration with the analog devices reference design and then thinking that I could just write up some sort of small uh processor side, application uh in vitis or or as the sdk from from vivado, and it looks like no need to actually go back further and do this all as a pedolinix creation.

A

And so this brings up something that we've struggled with in the past is well.

A

You know the assumption from from the tools designers from from xilinx specifically, is that they kind of assume that you have access to a board and that you can just program up an sd card and then put it pop it in so for when you're doing this all remote, it's it'd be better if you could just handle it all remote. So it looks like the. What we'll have to do is make an sd card and put it in there and boot from the sd card, and that's fine.

A

So we'll we'll proceed with onshore's advice: we are still waiting on the pluto, which is a parallel path, with the same encoder still waiting for evereest to publish his processor side software achievement. So the again the hdl side, the programmable logic side seems to be working and is that's very exciting um and then catching us up on the the processor side is really the key and then figuring out like how to what functions need to be implemented next.

A

So what we're talking about doing is is before the encoder really comes, the scheduler and and that's the place that we'll have decisions on who to queue up first uh and we we think that the metric is latency, so low latency applications through this particular communication system should get priority.

A

And then the open question is, if you request more bandwidth, how does that interact with the low latency request? So there is a lot of work done here in the literature and there's some some good best practices and we will get a chance to uh try all those out.

A

So if you're listening to this and you're interested in in all of this, then please join the list and welcome award and give us your opinions.

A

Okay, I think that's that's mainly what anshul had to say- and we will be talking about this on slack and the the conversation about the the uplink uh voice and data protocol will continue and we should have updates in the repo uh later on today, all right any other comments or questions before we close.

A

All right thanks, everybody all right, see you on slack and on the list, and next week same fpga time same fpga, channel for another round of reports and transparency for the community.

A

All right see you soon.

C