Open Research Institute M17 Project, 5 Feb 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 20220205 ORI Technical Advisory Committee Meeting

Description

Jump to:
M17 - CODEC2 work https://youtu.be/dou6hyj7SIc?t=86
M17 - Beyond RRCs https://youtu.be/dou6hyj7SIc?t=2263
M17 - Module 17 https://youtu.be/dou6hyj7SIc?t=2580
OpenRTX - RC-1 Board https://youtu.be/dou6hyj7SIc?t=2766
P4DX - End to End Demo progress https://youtu.be/dou6hyj7SIc?t=4677
Remote Labs - Polar Codes with MATLAB workflow https://youtu.be/dou6hyj7SIc?t=7306

A

B

And um about a minute we'll just turn it over to to avoid check, and he will talk about some, some really neat uh things.

B

uh What he's going to discuss is about codec 2 and optimizing codec 2 for to make it sound better, because our goal is to have our voice products and in amateur radio digital communications to sound as good as they possibly can, and we've heard, but we've been getting a lot of feedback that um the m17 voice quality could be better and wojciech's really kind of like dug in here and and is going to present some some ways that we can look at uh this challenge and maybe um publish some some really good work.

B

That'll that'll help us all right. So please take it away. Voice check.

C

Okay, so hello again greetings. My name is wojciech kaczmarski and I'm the current uh project lead in m17 project and also I'm a hum radio operator under the call sign, sp5wp okay, so we can get started uh and today's presentation is about uh quantizer optimization for codec2 and codec2 is based on lpc, linear, predictive coding. So it's a very popular framework for voice coding.

C

Codec2 is free to use and open source voice. Codec that has been developed by david rowe vk5, dj, dgr and david is also a ham radio operator and a lot of mostly hum radio operators helped him in development that voice coder and we are going to focus on the full rate mode, which is uh 3200 bits per second, and it gives already a good quality voice, but not as good as it can, as we will see later.

C

So how is the speech modeled and what is speech and speech is just a sound pressure wave that is generated by our vocal cords and it gets filtered by the vocal tract and gets output from our mouth and nose.

C

So we've got like an excitation source and the filter, and then the signal output and the problem is that uh for short periods of time and the excitation stays the same is stationary. We call this a linear time, invariant model.

C

So the excitation is changing over time, just as the filter does. So we can say that even if we said a letter r over- let's say half a second, it's going to be the same pitch and the filter made by the vocal tract.

C

So we can track those changes and we have to do it to reconstruct speech accurately and we can model the speed generation process, just as I said, by using an excitation source and the filter.

C

So this is a mathematical model for the speed generation, and this is how speech signal looks like, and this is a sample from our community manager, edward wilson and 2xddd, uh saying probably m17, and this is a sample of his voice. So we see that there is a difference between vowel sounds and sibilance, because sibilants have.

C

A high amount of zero crossings so for sibilance we just have a pressure wave that comes from the lungs and gets filtered by uh the vocal tract, but there is no. uh There is no uh vocal cord action in this, so it's not voiced.

C

We call that unvoiced speech so like saying like s or f, that's unvoiced speech and then there's a fragment of voice which is voiced, and you can see clearly that the zero zero crossing uh number is decreased and the pitch is visible and the pitch is uh just the difference between those samples right here. So it's the fundamental frequency for this fragment and you can see that it changes over time.

C

It's not constant, uh because the difference between those those two peaks is different than those two peaks, and this is the same speaker and this sample is 200 milliseconds long. So you can have a notion on how fast the rate of change is for a sample speech.

C

Now, let's get back to the uh mathematical model of speech synthesis so in real world we've got vocal cords and lungs as the excitation source and vocal tract as the filter and the mouth and nose is the output of the signal.

C

Now the mathematical model tells us that you can use an excitation source, which is just either a pulse train for voiced sounds like a or a or you can have a random source of random signal. I mean a noise signal that is filtered to produce sibilance like s or f, and then we have signal output, which is.

A

C

A time series of some values now the filter that is mathematic mathematical model of the vocal tract can be uh approximated, with an oppo digital filter of order p and usually, and in codec 2. The p is equal to 10, so we've got up to five four months. uh You can represent up to five four months so four months I will get back to this later. uh So this is the filter.

C

uh Transfer functions uh transfer function, h of that, and this is how 20 milliseconds of speech look like, and this is taken from the previous sample. So clearly it's visible that this is a voice speech, because there is a quasi-periodic signal- and this is 20 milliseconds of speech.

C

Now what codec2 does is that it extracts the filter coefficients a in this equation in the denominator.

C

And there are 10 parameters, a 10 coefficients for each frame, so you have to compute autocorrelation values for the speech frame and then use a recursive algorithm called levinson darbin algorithm to solve a set of linear equations to obtain a parameters from the speech sample, and this is how it looks like and the blue one, the blue curve or piecewise linear. But let's say it's a curve.

C

The blue plot is the discrete fourier transform of the speech input and you can see that the red curve is approximating the spectral envelope of the signal and the red curve is actually the frequency response of the a of that filter. Sorry h of that filter, which we just modeled right here so first we've got the speech frame. Then we extract a parameters from that frame and it gives us a filter like this.

C

So to describe this red curve, we use 10 a parameters coefficients, and this is a polynomial representation of the vocal tract and its filter. Now the other method of describing the filter is to use line. Spectral frequencies called lsf for short now when we, if we want, if we wanted to transmit parameters, a coefficient, a from one place to another of an rf link or something.

C

The problem is that uh those coefficients are very sensitive to errors and even a one percent error might make this filter unstable or the speech intelligent unintelligible.

C

So this is not good, so the solution for that problem is to convert the set of 10 a parameters into 10 line spectral frequencies, which describe the same thing, but lsf's are less susceptible to errors.

C

So this is that plot again that red curve- and you can see that those dashed lines represent uh line spectral frequencies and they come in pairs because uh when we say let's say, let's assume that this is uh the frequency response of a letter a or a phoneme r, because this this is not a letter. This is a phoneme.

C

We can see that for our brains, it's important to it's important, to have all those bumps in the right places, so those bumps are called formants and using 10, lsf's or 5 lsps. When, where lsp is line, inspector pair, you can represent 5 up to 5 formats, and you can see clearly that this plot has four the first one is very pronounced, because uh those two lsf's are very close together.

C

So the closer together are those lsf's, the higher the peak is- uh and this is the second one. This is the third one. This is very less very, uh not very pronounced, and there is also one here which is almost invisible, but it's right here. It's because those two lsfs are very far away from each other, so to have good, intelligible voice.

C

You have to know where each formant is, but the formant is just the bump. Remember you have to know where the bump is, how high is the peak and uh that's that's pretty much it for intelligible voice and uh also it's good to have this valley as low as possible. So the one of the limitations of the lsf representation of the spectral envelope of the signal is that this valley is not low enough, but we can do anything about it using a line prediction coding, a linear prediction coding.

C

Sorry- and this is just another representation of the previous plot when, where we have five pairs, five conjugate pairs of pulse of the all pole filter and you can see that it's indeed all paul fitter, because all of the zeros are of the origin and the red circles uh represent line spectral frequencies.

C

So right here, on the right hand, side, we've got a dc component and we go right up here when, where we have the nyquist frequency so somewhere about here, we've got two kilohertz, because the nyquist frequency is four kilohertz. uh This is just because uh the most used sample rate in audio processing is speech. Processing is eight kilohertz. That's the standard.

C

Now, how to encode lsfs, how codec2 encodes lsfs the first lsf well, every lsf is just a frequency from the range of 0 to 4 kilohertz.

C

Let's take a look at this plot again, so we have to transmit from one place to another set of 10 numbers, and we can say that those are integers 10 numbers to transmit how to do it efficiently.

C

Codec2. Does it like this? The first lsf is encoded as a codebook entry from a one.

D

C

It uses 10 code books, the first one is user, is used to encode lsf1 and it does it like this. Lsf input is compared to every single entry from that code book and that code book is. It has 32 entries.

C

So we look it up in the table in the code in the code book and, for example, let's say that the first lsf was 145 hertz, so the closest one is 150 and what codec2 does it? It actually subtracts every value from the code book from sorry.

C

It subtracts the input from every codebook entry and sees what's the difference between them and picks the one that is the closer, the closest one, the input. So in our case, it's 150 and of course we don't transmit that it was 150. We just transmit the index of that entry. So in our case it would be six.

C

So that's for the ls f1, the first lsf, so we've got nine more to go and next one. uh Well, the next step works like this. We've got lsf, it should say lsf, but david row uses names like this, so I'm consistent with that, so the first lsf was quantized to the value of 150 hertz instead of 145, which was the original one.

C

Now to tell uh now to search in the next code book, you have to subtract the value of the second lsf, so you have to subtract 150, so this quantized value from the original one. So our input and it shows that it's 410 hertz, so the closest one is 400.

C

So this is not. I have omitted the beginning of this code book and the tail, because there is not enough space to show it all, but it has 32 entries each of those code. Books has 52 entries so to encode lsf1 and at the ls f2 we've got already two integers two index two indices.

C

The first index is six and the second one. Let's say it's eight because we omitted some and we continue up to ls f10 and in this way we obtain 10 integers 10 indices to those code books. This is how codec 2 encodes lsfs.

C

Now the question is: can we improve that and it looks like very much can because uh those scalar quantizers are not optimized for uh the actual speed data, so we can either improve the scalar quantizer or move to vector quantizer.

C

How to generate a good codebook so to generate it? We have to obtain a long sample of speech and that's called speech corpus, and there are already prepared, like tens of gigabytes of speech, which can be downloaded for free and used for free, and one of the examples is open. Slr and ted lion is a part of open slr. As far as I know, and I have used those to generate code books for collective improvements.

C

uh I think I'm going to skip this for a second okay. So let's take a look at the lsf2 minus lsf1 difference distribution. So this is a probability density function of this difference and you can see that the most probable value is around 100 hertz. For this difference and the second plot, those points represent codec2 reference code book, which is the dlsp1 from this slide.

C

So we've got 52 entries of values that are spaced out by 25 hertz, so it goes from 25 to around 800. I think that the difference yes, it's it's uh uniform for the whole range, so it starts at 25 and ends at 800. so to effectively encode all this information.

C

You can use the fact that some values have more probability of appearance than the other, and you can see that values above 500 hertz have very low probability of appearance. So it's pretty much a waste of time and waste of bits to have all of these code book entries. So it's better to have less code book entries here and focus on this part, which has really good chance of appearance.

C

The next method is moving to vector quantizer, so the previous part used one dimensional quantizer called the scalar quantizer, where we had lsf's from one to ten and each lsf was encoded separately. So we didn't have to group them into let's say three-dimensional or four-dimensional vectors and in vector quantizing. uh We do that. So, first of all, we have to group all 10 lsfs into three groups, and the first group is the lsf from one two three then from four to six and from seven to ten, so the first vector is three-dimensional.

C

The second sub-vector is also three-dimensional and the last is four-dimensional. This is called the uh split vector quantizer. So, like you, don't you don't treat all the lsf's like as a 10 dimensional vector, and instead you split it into three smaller vectors.

C

And the method I have used- and I propose is that I'm using.

C

First, I'm using a course uh code book for the initial guess for the vector, so I've got 64 entries uh a 10 dimensional code book, that is so. I've got 64 entries of 10, dimensional vectors and and I'm trying to find the best one uh for my input, vector um and after I found it after I find it.

C

I move on to the parts that are sub vectors of three three and four dimensions, so the beta location for the proposed quantizer is that I'm using six bits for the course code book, which is uh 64 in uh 64 entries and then four bits per stage for the split vector quantizer and it's a multi-stage split, vector quantizer, because for each sub vector I've got either three or four stages. It's in the next slide. I believe so.

C

I've got three stages for lsf, one, two, three four stages for lsf: four, to six: to get a better approximation for those lsfs and three stages for the last uh four-dimensional part of the original lsf, and this gives 46 bits per frame while codec2 uses 50 in its original scalar quantizer. And this is how it looks like this is what you are waiting for.

C

So this is a set of 64 10 dimensional vectors, which you we use for the course search. So we've got a 10 dimensional input and we say we have to search the best the best fit from this set. So let's say it was the first one. Then we split this vector the original one into three subparts sub vectors and the first one is three dimensional, so lsfs from one to three.

C

So what we do is we take the first three dimensions.

C

The first three coordinates of the this code book this uh this entry and find the best uh entry from this code book that approximates the input the best, and we just follow this multi-stage path until the last stage, and we do the same for the next three, which has four stages and the last four dimensions.

C

And this time we have three stages now time for some mass to reconstruct the vector we let's go back here to reconstruct the vector uh we obtain.

C

11 coefficients well not coefficients but indices, so 9 from this part 10 from this part and 11 from this part, so we've got 11 indices to transmit uh to reconstruct the vector at the other side of the rf link. So this is how it's done, how the vector is reconstructed.

C

So we just take the I zero entry from the q0 code book and then add the uh i1k where case from one to the number of stages for the first part. So this is the first column.

C

So we add up all those vectors, then add up the another three dimensions and the last four dimensions of the lsf.

C

So this is how the vector quantizer works, and this is how the vector is being reconstructed based on the indices, and this is how the split vector quantizer converges. So this is basically show this basically shows how the error is minimized.

C

This is a two-dimensional cross-section for the training set for the q2 code book. So the red dots is just the difference between every qs q2 code book entry.

C

uh Well, it would be very difficult to see that the error converges to the origin, because the vector is three-dimensional, so it would be very, very dark.

C

So we see that at every stage the error is going to zero.

C

And this is the error distribution for uh q2 and we see that it follows probably a poisson distribution and the peak is less than five and five. Thousands and.

C

This is like the difference between the reconstructed vector: it's not the difference. It's the distance, the l2 norm for the reconstructed vector and the one that we input.

C

So we want to have zero, but of course we can't have zero, because we have limited number of stages if we had infinite number of stages or very big number of stages. This.

A

C

Would move to the left towards zero but of course we can't have that because that's that would take a lot of time to compute all this stuff and a lot of memory to uh to start this all those code books.

C

So, let's see the results of improving the scalar quantizer, which is originally used in codec2. So when we improve the code books for scalar quantizer.

C

The good side is that the computational complexity stays the same because there are no additional computations to make it's just uh one time when those code books are produced generated, and we don't have to do it again at any time, so you just distribute them over among the users and they just use it.

C

The spectral distortion is reduced because codebooks are pdf, optimized and pdf is the probability density function. So it's good to have pdf optimized code looks as it minimizes the spectrum, distortion and bitrate doesn't change, because we still have 32 code books and 52 entries for every code book.

C

So that's still the same amount of data now for the vector quantizer. It saves 200 bits per second for each frame for each second, because for each frame, instead of having 50 bits allocated to lsfs, we've got 46 and that saves 4 bits and there are 450.

C

Frames per second, which gives 200 bits per second gain.

C

The cost is that we have to do much more multiplications to find optimal vector and the spectral distortion rises, because there is a problem that the code book code books that we use are not optimized for a multi-stage, vector, quantizer and that's just another topic uh not covered today.

C

um I'm going to tell you more about this, uh probably next time as I have more results on the vector quantizer, oh, and even if the spectral distortion rises, it's not very perceptible because we are using low quality speakers in handheld transceivers.

C

So you have to have really good headsets headphones to notice the difference, and this is a spectrogram for each uh sample. The first one on the top is the original sample from m2xdd. So this is his voice and you can see that uh most of the energy is in the lower frequencies, so below one kilohertz. Even now, the next one is.

C

Codec2 encoded, so this is vanilla, codec2, the baseline for our research.

C

So uh you can see that there is some difference between uh the original voice and codec2 encoded voice like there is no uh frequency components below, let's say 100 hertz. This is just a blue line right here, blue blue part of the spectrum- and we don't have it here. It's just pink right to the dc.

C

The next one is improved: scalar quantizer with pdf optimized code books, and it's pretty much similar to this one. But some parts are.

C

Some parts might be reconstructed better, but it's pretty much hard to see any difference on the spectrogram. I would have to play the sample, which I don't have right now it's on the other pc, but pretty much. It looks the same as vanilla contact, 2, so visually. It looks pretty much the same now. The vector quantizer does pretty much bad job right here, and this is a vowel sound.

C

Let's say it's ah so in the vanilla, codec 2 you'll see that there are separate separate uh signals right here, uh harmonics and right here. You just have a blob that resembles this, but it's not as good as, for example, this one or vanilla cottage ii.

C

So the difference is imperceptible, but still it is there, but for 200 bits per second gain in compression. I think that's a good result. So that's it and thank you.

B

Thank you very much for watching all right, so the floor is open for a short amount of time. It's for questions. I'd like to direct technical questions to the chat. That would be the good. So if you have a particular technical question about the presentation, you've seen go ahead and post it in chat and voice will answer there.

B

If there is any um advisory comments or questions at a high level about the the work, uh the intention of the work or anything like that, then the floor is open for that right now so unmute and ask.

E

This is daniel with a question, I'm not sure exactly the category, but it's sort of a basic question regarding the codec, and that is one of the original assumption being that most of the speech is in the lower lower hertz, lower frequency.

E

But maybe the most important speech would be emergency speech or panicked speech whose frequencies are much higher and at the time people need their communication most. The codec might fail because of the implicit assumption of low frequency. Is that something to be concerned about.

C

No, I don't think so, because it just looks like this on the spectrogram, but codec2 doesn't care where the energy is focused on which range of frequencies. So there is nothing to be afraid of. Thank you.

E

B

Yeah any questions at all uh totally welcome in in chat for the rest of the session or at any time to anybody involved, but yeah any advisory level, input or advice for for voice check would be wonderful to hear now.

E

This is daniel again, I just want to applaud the progress that's being made in the codec. I think this is important work, so I I give accolades. Thank you very much.

B

Oh, thank you. It's wonderful to hear okay voice check. Please uh uh monitor chat, to see if anybody has some questions. They'll probably be thinking about your presentation and all the slides and the the video, and all of that will be available. uh We'll do our very best to to make sure that we edit and record and present all of this.

B

So the next thing on the agenda is the m17 project. It's beyond root, raised cosine filters and what we've been talking about doing is optimizing filtering for m17 implementations, because m17 wants to take full advantage of resource restricted hardware that anything that can be done to make the the rrc's better or higher performance is of interest.

B

So is anybody from m17 would like to present or talk about this.

B

I know that fred harris is very interested in this and wants to support it. He, he wrote me an email and said he was having trouble getting into the meeting today. So I'm trying to help him over email, but would there would there be anybody that would like to talk about this? A little bit more.

C

Looks like I would have to tell you about it.

B

Oh yeah go ahead. Please please do that'd be that'd, be wonderful!.

C

Okay, so I'm not very familiar with this topic, but I know something about it, so I'm going to try and tackle it. So the problem is that when you have to transmit stream using fsk, it's very wise to filter the base band so that it doesn't occupy infinite bandwidth, because imagine that you would have to transmit a stream of zeros and ones using fsk.

C

And let's say this is just a simple two fsk method. So you've got frequencies, f0 and f1. So if you just switch from one to the other, you would get a lot of frequency, uh spectral splatter, let's say so. It's very wise to first filter out the bit stream. So those transitions take more time but less than the symbol symbol time, and this is what we use in m17 and actually we use root, raised cosine filter for that purpose.

C

So when the basement is formed, we just take the bit stream input, upscale, it probably 10 times and then apply root, raised cosine filter at the transmitter and the same thing uh applies to the at the receiver side. So for the we just take the the modulator, the modulator output from the radio and then apply the same filtering at the receiver.

C

So in general we are getting zero inter-symbol interference because we just effectively used to convolve filter, which has which have.

C

Zero zero isi, when convolved.

C

A

C

To use a root raised, cosine filter at the transceiver and at the receiver, a transmitter and the receiver, and the problem is that the root raised, cosine filter uses.

C

It doesn't have very good performance when, compared to some other that has been pro has been proposed by someone on twitter and someone proposed that a modified parks, mcclellan method might be used to obtain a filter which has the same performance but uses less tabs, and with that it means that it requires less computational complexity and does the same job. Basically, so the proposal is to use, modify modified park, smack method to obtain new tabs and use them both at the transmitter and receiver side.

C

So this is probably everything that I have to say about this topic.

B

Oh, thank you, I think that's a very solid summary all right, so we'll follow up later on with uh probably a more expanded uh uh presentation um on this particular topic, because we've really just only started looking at it any questions uh from a like an advisory point of view. uh Please go ahead and ask them, and if there's any technical questions about this particular part, then put them in the chat.

B

Okay, all right, the next item on the agenda is module 17 and who is speaking about module 17 today, oh someone says, give me a minute: it floated.

F

Across my screen, that's matt.

B

Oh hello, matt, okay, yes, uh please uh do you have the floor whenever you're ready and if you need anything just let me know.

D

Okay, uh thank you michelle. Can you hear me.

B

Yes, I can hear you and see you.

D

My name is matis or matt db9 mit, and I am currently working on module 17 and just to to show you what it is.

D

If I try to focus um so this is, this is basically the the current development board for module 17 and um what the idea for this board is um to to be a device that is running the open, rtx firmware and through that we'll be able to modulate and demodulate m17, and the idea is to to be able to connect this this board um to a 9k6 bot, compatible radio, be it a mobile radio or a handset and to be yeah quite easily and cheaply be able to to transmit and receive m17.

D

um Currently, we, we went through three revisions so far, so we're at 0.1c.

D

And it's it's looking promising so far, basic openrtx is running on it. The open rtx guys are working on getting the modulator and demodulator working on this on this module, so it it shares the same microprocessor as the.

D

What are they called the the md 380 radios are using, um so a lot can be reused. What has been been written for that um and yeah so currently what you? What the idea is for these ports is that you, you connect a a speaker mic to it and use that to to transmit, um but the the goal for for the final revision is to have something in in this form factor, maybe maybe a bit bigger than uh so. This is the usual kenwood style. Speaker mic um to yeah have a board in here.

D

Maybe a small display that you can can connect to your mobile radio and directly transmit and receive m17 yeah. I think that's more or less it. What I can show you without being being prepared. um If there are any questions, uh please go ahead, be happy to answer them.

B

Oh sure, yeah, um and if you, if you haven't um already directed people to where the documentation and repository is where would that be all right, very good, all right. The next item up, we are a little bit early, but it is the open, rtx, rc rc-1 board,.

B

And I believe that the open rtx team is going to present on that and you have the floor.

F

Yes, yes, thank you, michelle, I'm going to present about the rc1 project. Just give me a minute to set up my laptop.

F

First of all, I'm federico- and I am one of the three members of the open rtx project, and here here tonight with me- should be nicole. Also connected to this call.

G

F

To everyone: okay, today we are talking about uh one of the the ideas that came to our open rtx team and the idea is about the radio card. One. First of all, let's talk about what is open rtx for the one that do not know already.

F

Basically, it is a free and open source alternative firmware for digital harm radios, and the idea is to develop a firmware which can be used on multiple models, types of radio devices, and we, what we want to do is to bring bring forward a community driven development so that everyone with the skills and the will to let's say work with us- can participate in the project and submit code or bring new ideas, and also we want open rtx to work on on as many radios as possible.

F

We don't want it to be constrained to just one single model. Also, we would like to have some reviews of features and code across the various targets.

F

The various radio devices we are going to to support and a final goal could be that we we want to to have a software platform which can be used as a base for ham, radio, experimentation, which is something that is really lacking in my opinion, because the the great part of the hammer- radio, let's say andy talk- is or mobile radios. They feature a proprietary software which cannot be modified and uh there have been some some attempt. But uh right now it was missing. I mean uh a great software platform to experiment and dock icon.

F

So this is what open open rtx is about, and right now the open rtx can be installed on cheap chinese dmr radios. An example is the thaitera md380 and all its multiple clones, and also we are working right now on supporting the alan's hd-1.

F

Next, we we would like to also extend the support to jaisu ft uh 1ft2d radios, which are pretty cheap and and well build. So this uh extending the support to these radios would be great and also in the future. We would like to to see our some new hardware, some radio built from scratch to to better suit the the experimentation.

F

Okay, we have to talk about hardware, implementing protocols, some radio protocols in hardware or in software, because there is an important difference. Most radios there we see on the market, like probably any dmr radio they employ. They implement the dmr protocol in a hardware way, which means that there is a dedicated, baseband chip.

F

You see this uh is uh the basemanship, the hrc 5000, which is used on the md, 380 radio and basically, in these types of radio. We have this chip, which does implements fully the dmr protocol well, except for the vocoder, which is strangely done by the mcu, and the the most important part about this picture is that the microphone and the speaker?

F

They are connected directly to the basement chip, so they are not connected at all to the host microcontroller, the the mcu.

F

So what does this mean? Is that these dmr radios, that they do they implement the protocol in hardware?

F

The the main microcontroller has no way to receive the basement signal or to even to output, some some audio to the to the speaker, because it's all handled by a dedicated chip so but unfortunately, the dedicated ship. Just does the dmr and if we want to do n17 with our radio, we need to work around this limitation.

F

What what we have done so far is to research, some hardware, modifications which add the missing audio paths to the to this radio. Basically, we add the mcu the capability to receive and transmit arbitrary audio signals over the radio, and we had the ability to receive microphone, input and transmit speaker output.

F

But still up until now on the market, it is really missing a cheap and duckable radio. Because from this uh we just said that uh cheap dmr radio need to to have another modification done before they can really be used to do, let's say to try to encode arbitrary protocols.

F

We just need on the market, a radio on which you can do some protocol research or implement new protocols without having to deeply modify it, and this was probably the the question that that we were asking ourselves and gave as an answer the the idea of the radio card.

F

The idea behind the radio card concept is to create a radio building block, so we want, to, let's say, create the minimum, the minimum working device which can which allows us to transmit and receive arbitrary protocols on the on the airwaves.

F

So we want to create a really minimal module and we want to give it a standardized interface so that it has some connectors and you know how to interface with this module, and the idea is to use this core radio module on multiple application, some of it. Some of these may be an nd talk for, for example, or a mobile radio, or just fitting it into a laptop to have a radio modem into a laptop or otherwise.

F

We can also construct a repeater or any other application that might might require a transceiver transmitter and receiver radio device.

F

So what what do we want to do with this radio minimal radio module for the protocol standpoint?

F

We would like to do first of all, an analog voice and also, of course, we would like to do some digital voice, for example with the m17 protocol, and let's say we: we want to give it the ability to encode and decode software protocols.

F

So the idea is that, if, if you want to experiment with other protocols, you should be able to do and while from the radio features a point of view, we want to target the vhf and uhf band because they are the the most widespread and widely used band in their ham, radio scene. I think, and also we want this module to have a low power output and the optional external amplifier, because limiting the module to to being low power.

F

It takes us off a lot of problems, for example the heat dissipation or the power consumption.

F

uh Let's say the idea behind this is that you can do also stuff, even without an external amplifier, so the module is useful even at low power, but there must be the possibility of attaching an external amplifier if your application needs it.

F

Talking about the form factor, we are looking at the m.2 form factor because it's really widely adopted among the development boards. There are really a lot of boards for developers and makers that use this for factor and they they are right in some sense, because it has a lot of advantages.

F

First of all, right now it is the dominant standard for interconnection inside laptops.

F

Almost everything that plugs inside your laptop, like wi-fi card, ssd, storage or lte modem, uses a variant of the m2 standard.

F

Also, it gives you a lot of pins right, maybe around 40 pins and also, if we pick the m.2 b key, which is a particular notch configuration of the connector.

F

If we choose this particular configuration, our module will fit in a laptop modem slot, which is really great because you can just add a fm and multi-protocol transceiver module to your laptop without without doing some ugly modifications you just have some predisposition by the manufacturer.

F

Okay, finally, let's talk about the development of this. This idea.

F

From the architectural point of view, the architecture is is pretty simple: basically, we need to have a standalone radio functionality which can interface with the outside world from one side with the m2 connector and from the other side, with the antenna connector.

F

So the two main building blocks that we need to to create this application is a microcontroller which will run the open, rtx firmware, obviously and we'll take care of protocol encoding and decoding, and also we take care of interfacing with the other side of the m2 connector, be it your laptop or the nd toolkit, let's say carrier board, so we have a microcontroller unit and a radio chip right now we selected the adf7021 which, because it's the one on which we got so we got the let's say most clause to do m17, transmission and decoding.

F

uh Also here we have a an lna and reception amplifier, but this this item is still being discussed to whether to include it in the module or to use a separate. Let's say to put it outside the module.

F

Okay, we are, we are developing dissolver project using the keycard open source eda, and the schematic is mostly done because most of the the connections are complete, but for for the layout we are still early in the work, but uh also probably because we don't want to commit we to start working on the layout until we are quite sure that we have the final schematic, because otherwise we risk having to do it from scratch.

F

So, right now we are still trying to finish the schematic.

F

And finally, here are the the three open points uh which are questions to which we haven't found. Yet an answer. The first of all is uh the silicon shortage problem that causes basically the microcontroller. We have selected the radio chip which are hard really hard to obtain, and this has a in sort of discouraged us to commit to complete the schematic and to do production, because if we cannot buy one of the two main chips, we cannot even let's say, build the final prototype uh other than that we are.

F

We have still to to decide what will be the low noise, amplifier and power amplifier multiplexing configuration so whether to put the two amplifiers inside the module outside the module or one inside the other side, and how to manage the connection and the let's say, selection of the two amplifiers.

F

This is still being debated and also we we have some doubts about the the adf 7021 uh usability in in this application, because wojciech has has designed a development board for this radio chip, but he still hasn't got some promising results from it. So we still are not. We are not sure 100 percent sure that this radio chip is suitable for our application.

F

Okay, my presentation is finished, so if there are any questions.

B

Yeah, thank you so much as the floor is open for questions and also chat. If you have a some sort of a very technical question, then it might be better in chat, but please uh the floor is open for questions.

B

Go ahead, daniel.

E

The federico the excellent presentation very interested in the project question I have for you, you mentioned the desirability for compatibility with the m2 b slot, typically used by the wlan or the wi-fi part of the circuit board, I'm not sure which, but my concern is the antenna generally. I wouldn't think that the wlan or wi-fi have the correct antenna design built into a laptop for vhf or uhf signals. Do you envision any?

E

uh How would you envision possibly utilizing that, or is there a separate antenna going to be required.

F

Okay, thank you, daniel for the question uh you are exactly right.

F

In particular, the b key I was mentioning is the one used by the modem, like a cellular modem in laptops and usually laptops that have uh how do you, let's say a predisposition for this kind of modems. They also include antennas cellular antennas, which are usually placed in the laptop screen and the cables end up near to the modem slot, but I think that definitely we can't use these built-in antennas because they are tuned to be in the range of cellular networks.

F

So this point of placing an antenna in a usable position for the radio card inside the laptop is still a problem which we haven't figured out yet, but I think there are two possibilities. A first possibility is to use a pigtail connector that plugs into the radio card module and you can, let's say, bring it outside your laptop, maybe using a hole, for example the kensington hole for uh for the keychain, and this way you will have a connector outside this, uh your laptop, which may be a solution.

F

Another solution could be uh finding some patch antennas so like antennas, which are build of a pcb, and these could be embedded on the back side of the laptop, but this solution is really less than optimal.

E

Excellent. Thank you. Thank you very much.

B

Well, thank you, hey. I have a question from um the uplink team over on p4dx and they were interested to know um about whether or not you would consider the axm 0f243.

B

Chip for this sort of sort of work because it looks like it might be a decent match.

F

Actually, I I really don't know this chip, so we definitely haven't considered. It is the axn0f243 right.

B

Yeah, correct yeah, we'll talk about it later then I maybe yeah you can. You can tell us if it might might help out in uh in some of the ways or be a parallel path forward.

F

uh Okay, okay, but oh wait uh just realized that we actually have either look at it. It is a really cool chip because it integrates a microcontroller and a ax 5043 radio chip. So it's a like a combined microcontroller and a radio chip, and this is very cool because it will let us complete the radio card with a single chip instead of two, but since the chip it includes to use to, let's say, transmit analog fm.

F

We have to use the a special mode which is hidden in the data sheet. So I my fear is that this combined chip doesn't have the capability of transmitting analog fm modulation, but we can for sure, look look into it because it might be a really good match. Thank you for the.

B

Suggestion, okay sure, might.

C

B

Of course, please go ahead.

C

uh Thank you. I've got some experience with ax 5043 and it looks like it can run something that I would call a vco mode, so it it's able to transmit continuous life, and it has two differential inputs, just adcs that can be fed with base band, and I have already confirmed that m17 works in takes mode on that chip, but the problem is that the receiver part it's not very good, because the output level is either very low or is very quantized.

C

So it's not a very good chip after all, for tx is very good, but for rx it's not very good and that's it.

B

Oh yeah, thank you.

C

B

A lot of sense since the chip was being looked at for uplink, um so so that was where the focus was. Thank you very much for the feedback on the receiver.

F

F

C

Sorry I have ordered uh two evaluation boards for cc 1200, so that's also an rf chip which looks better than ax 5043, because it doesn't use analog input for the baseband and instead you can use um you can use spi to write or read from a register and set the frequency using this method using digital spi and uh what is better than that ax 5043 is that it uses internal, let's say up sampler.

C

So there is very minimal spectral splatter from that chip, so it should be able to transmit m17 and as well as receiving it. So for me it's a good fit. So, let's see, I should receive it on monday from mauser. So let's see.

B

Excellent, thank you so much all right, any other comments or questions. Please you have the floor.

E

One more question: frederico, I'm not familiar with your project. What are the target data rates you are hoping to achieve in the vhf or uhf bands.

F

um Okay, for I, it really depends on on the protocol. I our target protocol, where n17 and like aprs, so I think the data rates required by m17 might be a suitable, a suitable, let's say, target requirement for that.

E

F

Maybe nicole knows more.

G

A

G

Anyways, we are targeting uh narrowband protocols with uh low data rate uh for now um that, because it simplifies the choice of uh the the radio module, but uh if basically uh an application for a higher data rate comes into mind, we can still uh uh either uh study the the use case or try to derive a different. uh Let's say designer, using uh similar components.

G

um The whole um project tends to be open hardware and the software we will write will be open, open source. So we also aim to be the basis for a future development which could take also different directions.

B

All right, fantastic, okay: we are ahead of schedule and we have presenters that will be here uh in about 43 minutes, it'll be 1100 hours, my time, u.s pacific. So it's open discussion. The room is open and, and please feel free to hang out. We will resume our formal presentation schedule at 1100 pacific and uh thank you. What we'll do next is uh talk about the end to end demonstration for phase four dx or p40x.

B

uh This is a microwave band, um a digital multiplexing transceiver project intended for both space and terrestrial on the 5 gigahertz band. It is a frequency division, multiple access link up and the base digital protocol. Our native protocol is the m17 protocol.

B

Once those signals are transmitted up to the to payload or to ground sat, then it is turned into a dvb s2 signal, a time division, multiplexing signal down on 10 gigahertz, so there's plenty going on with fpga development and demonstrations and all sorts of fun things with vorader correction. After that is a discussion about our work on uh we're, anticipating work on polar codes.

B

um These are very exciting codes and there's lots of peril in working with them because they are also used in 5g. So we have plenty of patent issues to to look at, and some regulatory and legal efforts to to clear, but our intent in order to support the technical side of this is to enable a matlab workflow, so that people in universities that are working on a publishing in polar code area will be have some familiar resources at remote labs.

B

So those are the things that will come up in about 42 minutes and until then, please feel free to take a break or discuss anything. You like here on this particular conference, see you in a bit.

B

Hello, fred up, don't have your audio. Yet, let's see, if I can fix that from here now it shows you're, not muted. Oh there you go oh hi there, hello welcome! Well! Thank you, I'm very sorry for the difficulty you had and.

H

No problem, I appreciate that we're on thank.

B

You yeah no, if you'd like to talk a little bit, uh we have the recording, is still running um okay and then we'll. We have about 10 minutes before uh the pick back up, but uh I think that everybody would be totally okay with you uh presenting or talking about anything you'd like.

H

Well, I'm primarily listening and willing to answer questions if there are any.

B

Oh very good: yeah we had a discussion about the root, raise cosine filter, work on um for resource restricted hardware, um so I'll make sure that you hear what uh vojtech said: okay.

H

B

So that's that's essentially the the area and then, of course, anything else. You'd like to comment on.

B

I think what we have coming up next is um oh stuff that you've you, you know a bit about the uh end-to-end demo and ldpc encoders and then a little bit about polar codes, so we're trying to look at polar codes, although we do have some concerns on the patent side to on how much we can get away with in terms of open source and our method of attack here is to use matlab all the way through to hdl coding on the remote lab development stations that are all xilinx ultra scale devices.

B

So that's the stuff that's coming up here in 10 minutes, okay,.

H

Good I'll be stepping in and out, I've got another zoom. Oh.

B

Yeah no problem yeah and no problem and if all goes well, this is recorded. So you can, you can watch it later. Yeah.

A

B

B

All right, thomas and andre, you have the floor. Whoever would like to present first open discussion or discuss uh advisory issues. uh Please uh proceed.

I

um uh Andre d: do you have a presentation, you're gonna show.

J

Yeah, I was hi everyone by the way, so um so I'm gonna start with the um so well. This is the diagram as it appears in the spec and I'm going to start with the rf rf side here, and essentially everything to the right of this is platform dependent. So we thought of the scope.

J

The current implementation starts with the stream adaptation here. So the scope of the encoder as of today is the baseband scrum scrambler fact: encoding beats mapping physical layer framing and modulation right now we don't have padder or physical layer, signaling or pilot insertion, and but we do plan to insert to add those as well.

J

um So next thing is how to interact with it, and so let me open my notes just a second okay, so the encoder receives baseband frames in the inputs and produces modulated physical layer frames at the output, and the interface we chose is like the stream for both and the input stream interface carries the configuration for the frame and but we have frame length, consolation and code rate.

J

So these three make up what I call frame attributes and they define. You know how the frame should be processed in the system. There are many parts make up a regular access stream.

J

The output interface is very similar, um but without the frame based parts, um for example. At this point, data has been modulated, so empty data is going to have inq components.

J

Besides these, we have malaxia light interface for memory, mapped register access, and this register space has essentially three main uses that are going to be configuration, status and debugging, and we need to configure bitmapper tables.

J

We can enable dummy or disable them frame insertion, and then we need to write, filter coefficients and status and debugging are for things like monitoring, behavior, controlling flow of data, and- and that applies to several points in several internal interfaces.

J

We can, for example, check how many flight frames in fights we have- I don't know biggest smallest frame- that has gone through a certain stage. We can also block data and block the stream at a point and allow one word or one frame at a time to see how the system behaves.

J

um The timing of the of input and output looks like this, and in this example, the input frame is configured as short frame, qpsk code radon for one fourth and the receiver. Sorry, the encoder received this and at some point, is gonna write to the output frame um and by the way this is what I mean when I say, parameters are constant during the frame as in the values in the ports are constants. While data has been transmitted.

J

Last thing on the intro is how the system looks like, so this is a high-level block, diagram of the encoder itself and as it's implemented in rtl um and these red blocks here are the stream debug stuff that will allow blocking data stream and allowing one word one frame at a time.

J

A key difference of this diagram um between this diagram and the functional diagram of the spec is oops. Oops is the presence of this frame fifo and besides the beats interleaver and it's going to be used for qpsk, because qpsk has no beats interleaving yeah, just a second.

J

So ever every block in the system looks similar to this, and most dvd specific blocks will also have frame attributes, and but the thing is, we cannot change them like this because, for example, this block this green block on the right and has nowhere to get um frame attributes from so to support.

B

J

Having a different configuration, we need to transport this configuration alongside the frame itself. Then we do this by using a maxi, tid interface.

J

In this case, the arbitrage data is the configuration of the frame and in this grey block, for example, we need frame length, consolation and code rate so with the code tid, oh crap, so with the quality id to extract um when everything yield just works, uh we can use this to transport.

J

Anything that's constant during the frame, and that makes it simple to connect multiple components, and so this is like the top level, and you can see that the frame configuration here is encoded um into an sdid vector and that's how it's transported throughout the design um so yeah. This concludes the intro stuff and so stepping into the baseband scrambler, and so the baseband scrambler is it's a nice first block to look at first, because it's very simple.

J

So this is the text in the spec I'm not going to read. So I'm just going to highlight like the key things are. There is a um engine as we need to follow.

J

The baseband scrambler has a feedback shift register with a certain polynomial and we need to load this shift register with shift register with a specific sequence at the beginning of every frame.

J

um So the spec provides a diagram that is very close to the rtl implementation and like this is the 15 bit shift register and data moves from the left to the right. Every time a data bit comes in, and so we take bits 14 and 15 and end them and sorry and add them together and to get the new value of bit one and to guess the output.

J

We only we only need to xor bit one of the lfsr with the data input, um so the block diagram is simple and we have the lfsr with an initial value, and so the lfsr is going to be reset when the system is reset, as in the master, reset or power on reset or when st last t-last is asserted, and that indicates this frame completed. So we reset the lfs argument. Preparation for the next frame um bit 0 then, is xor with the input data that produces the output data and yeah.

J

I'm just going to skip this so back in coding. Just a second.

J

um So fake encoding subsystem is made of three components: the bch encoder lgpc encoder and beats interleaving.

J

So looking at the bch encoding, um so it takes a baseband frame as an input and appends a parity check code to it. The size of disparity check code is given indirectly in the spec, and the size depends on frame length and code rate.

J

The size of the bb frame is given in this sort. The size of the bb frame is given in the this column, which has it it's essentially bch encoded block um and the size of the effect. The bch fact code word is, then you know the difference between the bch coded block and the bch uncoded block and to actually calculate the parity and the parity check code. We use this set of polynomials and so frame length and code rate identify which polynomial index should be used, and this in turn identifies the polynomial itself.

J

So this h encoder block diagram and I'm going to stop using like individual um lines, so I'm just going to and coalesce them together and so wait yeah. So the crc max does the core crc calculation, and that includes selecting the appropriate polynomial.

J

So this block has a constant latency so um to make our life easier- and we add this access stream delay here at the bottom and to delay the data for um the same amount.

J

So when, when data arrives at the output max, you know it's easy to choose where to which one to output, and also the crc max block, has no back pressure, which means this dashed line is literally like a tap. We don't need to replicate streams and manage back. Pressure is just literally tapping off.

J

So if we can look at this um from the data flow point of view, oh sorry, I forgot one.

J

J

When a frame completes, we need to multiplex between um the data that is passing through by this axis stream delay and the data that the parity data, so essentially when they, when the frame completes, we count how many um output words. We need to put to write the parity bit parity code word.

J

The paragraph parity code word is usually bigger than the data width and we convert using this ship register um so yeah now, looking at the data flow, so uh wait.

J

Yeah the baseband frame flows through the output um directly and through the sears through the crc block. So yes, the crc max and once stlast is asserted indicating that the input frame completed. We count the number of words needed to shift data from the crc flip-flop to the output through the shift register.

J

um But by the way this crc blocks here are auto-generated.

J

Yeah, I plan to put a link to the ones I used, um but essentially any auto generated, crc block with this.

J

The correct configuration should work here um then moving on to the ldpc encoding, and so this is the most complex block in the system, but I think it's the most interesting and so the fact encoding subsystem receives the biggest band frame adds a bch fact code and an dpc faq code, and this pack gives the size of each of the spec if the size of each one of these blocks in the same table as the bch stuff, the size of the ldpc effect codeword is given by the difference between the ldpc coded block and the ldpc uncoded block and the other pc encoder block size only depends on the frame really.

J

But the ldpc encoded block depends on frame length, um encode code rate, um yeah.

B

J

Is the stat that text for the ldpc encoding in the spec, but um so I'm not gonna read this um I'm gonna, so I I made like a series of slides to um show this at the pc code in a minute or so so let me wait.

J

So we start with a data frame, so this data frame has a certain length and for the matter of this example, the length doesn't matter, but the spec refers to this as kldpc, so this frame is divided into 360 bits uh in groups of 360 beats each and and the parity bits will be stored in a memory that I'm gonna call. Parity memory um in each data bit will be x, stored with the values pointed by offsets given by the parity bit address table.

J

So each group of 360 bits will use one row from the parity address table like this, so um the first bit of the first group uses row zero and I'm so I'm putting some numbers just so. These are arbitrary numbers and just to help visualize and so bit. 0 will be added. That is xor in offsets. 3, 5, 7 and 11..

J

The second bit also, you also uses row 0, but we add q to the offset and q is a an integer that is function of frame, length and code rate, and for this example let's say: q equals three. So for bit one the offset is going to be um three plus three, so six, five plus three seven plus three and then eleven plus three.

J

The third bit is the same, except instead of adding q, we add two q, so three plus six here and then yeah the others.

J

The remaining bits of this group will use the same process over row: zero um incrementing, the multiplier of q. Each time and the remaining groups will is the same process, but um we have their associate rows and we reset the q multiplier to zero. Every time we get a new row.

J

So once all groups finished, um the parity memory will have almost the fak code word. So for the next step, we only look at the parity memory, so we take a sliding window of two.

J

J

So we end yeah, we add these together to get one bit of the final code. Word then slide the window by one to get the next bit and essentially do this for the entire memory, and that will give the final output final ldbc code word.

J

That's the thing that is going to be then appended to the to the frame.

J

So the lgpc encoder, so I'm gonna, divide and conquer right. So there's a the ldpc table that is responsible for essentially unrolling the table. So it will pick the correct base table and add q appropriately track. The 360 bits group and all of that and essentially will prepare the beat addresses and the ldpc core will do the actual calculation.

J

So looking at the ldpc table first, um so this is it's nice to separate, um because a dedicated module makes testing way easier.

J

um Well, there is 21 tables, there is varying number of coefficients in each table, but essentially there's like six and a half thousand coefficients and each coefficient is 16 bit wide um so and we also need to unroll the tables on the fly um like we one of the alternatives I consider was basically unrolling the table and then storing that, but it's prohibitively really prohibitively big. So it it's not feasible.

J

um So it doesn't matter what the tables are, but they all sort of look like this in the specs. So this is one a quadrature of one fourth, a third three fifths and two thirds. So if we look, I don't if we just zoom into this, it's going to have two sections.

J

The one at the top is 12 by 15, so 12 rows of 15 values each and the bottom is 30 by three.

J

um The next um table looks it's looks similar, so 12 20 by 12 and then 12 by 3 and yeah. The next one is the same, but 36 by 12 and 72 by three, and in fact um all tables have two sections and the number of rows and columns is constant in each section and we can use this store advantage to build a generic table reader.

J

So we store the shape of each table in one memory that I'm calling metadata memory and we've flattened all the tables themselves into another memory and that's going to help a lot with resource usage.

J

And how that works is so suppose this is a table, um I'm just keeping it small to you know, keep simple so we're separating the shape into one side and sorry the data in one side and the shaping in the other side, and- and you know when we separate the data we flatten them- we're gonna see in a second how that looks like. So, if I have a memory that has this somewhere, I need to know where this the table starts.

J

What's the size, the shape of the first region and the shape of the second region and suppose another table looks like this, we do the same and again we're gonna need. You know where disables we we need to know where this table starts and this the shape of the of the first region and then the shape of the second region and yeah. We keep doing this for all tables and, in the end, oh sorry, um to unroll the table.

J

We also need the values of q, and so they sort of feature fit naturally in the metadata table, as well, so to unroll. So, in the end, we're going to have offline and parity address tables placed continuously in one room and all the metadata is stored in a much smaller room um and the net result is, you know the parity bit address. Table memory is around 100 kilobit and it's gonna use seven block ram 18s, um which is good. It's not not bad devices.

J

Have I don't know, hundreds of these and the metadata memory is much slower. Much lower usage is around one kilobit. um It is usually mapped to. Let's look up. Tables um is yeah for reasons.

J

That's just generally what happens yeah so the ldpc table.

J

So if how this works in hardware, so uh frame type and code rate address the metadata table, the metadata table outputs the relevant information to the what I call the unroll logic and then religion, bro logic will use this information to read um the coefficients from the parish. The address table and enroll them to generate the final offsets.

J

So, oh yeah, so enroll logic is simple: it's just a bunch of nested counters. As in I need to count this many rows. You know this many columns and it's so there is always two sections, so you know I yeah.

J

I just need to um it's just counters, so yeah, I'm gonna skip this timing wise, so um a single beat will start the process and the ldpc table will produce one offset per clock cycle like this, and it will also produce another output column next, which essentially marks whenever a row completes and which means um like a new bit can be processed.

J

So this means that, for example, this section here with coefficients 3, 5, 7 and 11 related to data bit 0 and then the next one you know 6 8, 10 14 are for bit 1 and and so on and so forth, and these values are the same for the example of the ldpc in a minute slide.

J

So q equals three right and we can see that um when we get a new row which mean a new bit and the coefficients are just added by q. So this happens here and then here and here and so on, so the core encoding. Then the so block diagram looks like this, and so this wait.

J

This block takes data and table as inputs. The input data stream is replicated into two branches and replicating here means um a single stream becomes multiple streams in this case too.

J

In this case, so this allows um output, but the output mux and the input synchronizer blocks to back pressure towards and data input, and so the branch on the top goes straight to the output and the other ones go through um the input synchronizer through to the ldpc accumulation.

J

So the ldpc accumulation logic uses offsets from the ldpc table to xor data in the associated positions and of the parity ram and and while that's going on it will keep the output mug, selecting data from the extra stream replicate, and that is essentially the baseband plus bch fact frame passing through.

J

So once the input frame completes, it will switch to receive data from the post frame accumulation, slash with conversion the frame ram, yeah. The parity ram, sorry uses a block frame internally and block. Oh sorry, yeah yeah and block rims data width are naturally 16 bits technically 18 because dcc but yeah review 16..

J

um So we need this width converter from 16 to n um to convert from whatever sorry from 16 bits to whatever the output with is um so looking at the ldpc input. Synchronizer um yeah. We essentially use this to synchronize table offsets to data bits so because the parity bit and offsets are given one per cycle.

J

We need to convert the input data stream to one bit as well, and this ensures that output data and output offsets are synchronized, um so data will pass through the width converter.

J

It will be converted to one bit and the table offset passes literally through and the output will be valid when both with converter converter and table have data like this and a bit from the width converter can be consumed when the ldpc table indicates a next like I showed in the diagram, and the reader is also ready to consume that data as well, and we can consume one offset from the ldpc table whenever there is a valid data bit and the reader is ready to consume this bit as well.

J

So it's not yeah, it's just the width converter with some ends and gates around it.

J

In just a second.

J

The accumulation process is sort of the heart of the encoding and, to this block connects directly to the input synchronizer and here offsets are used to read the parity ram and because, and each ram address holds a 16 bit value. We divide the offset by 16 and use the remainder of the division to select um which bit of the read data we need to operate on, essentially um so within xor that input data with the appropriate bit. It writes the result back to memory and.

J

So block rams have an intrinsic to cycle latency between read, address and read data, and this means this doing. This is limited to one operation, every three cycles and it which is not good, but so we can do better right.

J

So if we switch stuff a little bit and essentially these flops here match the read match the ram read latency and this way we can decouple, read and write addresses in time because we don't need to hold the read address constant while re while write data is getting ready and by the way I call this pipeline now.

J

um However, this two cycle latency also applies between um write data and read data, and then this is an issue in cases where we're reading data from an address that has been written less than two cycles ago and like data will not make to the read part in time as we expect- and this is called a data hazard and unfortunately, unfortunately in the ldpc, this happens, but so this is solved inside the parity frame itself uh by doing some tricks around the block rim.

J

So the accuracy storage is still the block ram, but but we had some flip-flops um to store pending rights, which are rights that have not yet been committed to the block rim itself, so read, address and is still connected to the block rim, of course, but it's also used to check if the address being read is pending, so that um read, data will always have the most up-to-date data, so in other words, read data can be either data from the blog ram or from one of the pending, writes so suppose.

J

We're reading and writing from the same address at the same cycle, so write, address, write, data and read address will still go to the block rim, but we can compare the write and read addresses and if they match we bypass write data directly to read data.

J

So if we're reading from an address written in the previous cycle, um we can do the same with data after the first flip-flop and likewise for reading an address written in two cycles. I go with them the second flip-flop and then anything later than this or over two cycles. Data will just come from the block ram itself, um and that is it really like that I put like yo. I.

B

J

We had time just to cover these three. We didn't cover a bit interlibrary constellation, mapper physical airframe and polyphase filter.

J

um So currently we we have um verified in simulation and hardware and all 84 valid configuration, combinations and we're bringing up the over-the-air setup and by the way, so michelle and paul are doing most of the work here. I wish I had more time to help um at this image on. The right is my is my local setup and, and that is it really so I put links you know getting involved, um yes, yeah contacts for myself and well. This is not a typo right.

J

There is a story, but it's different from my last name, but it's not a typo.

B

Very good wow. Thank you so much any advisory discussions. Please take the floor and if there's any technical questions go ahead and put them in chat and.

H

B

You have any follow up later on know that this will be if all goes well. This is recorded and will be edited up and up later today, and you can continue to reach out and ask questions about what you've seen but I'll turn the floor over to anybody. That would like to ask any or give any advice or have any advisory input or any high-level questions. And then please ask any technical questions in chat.

E

Dr soto, this is daniel, oh hi, hi hi. uh I was a little confused at the beginning. The the forward error corrections. Well, a lot of the error. Correcting code is listed as fec. I I understand that's forward. Error correction. Is that right.

G

E

Yeah but yet they're being inserted after the fact. So I I got confused because how is the forward error, correction, yeah,.

A

E

That work exactly it's being started afterwards, not forward.

J

uh It's for I, so I'm not an expert on this. I I basically read the spec, but my understanding is you add the error correction stuff before you send over the air, so the receiver yeah can use. It will essentially like receive more information.

J

So if there is like eruption, it will um recover so like there's beats interleaving that, after the the the fact that will essentially distribute the fak codes around. So if you lose a burst like you lose part of the error correctly, you don't lose everything.

E

You can recorrect so how much latency is in the spectrum, because we're doing that, in other words, you're holding up the data that you have not transmitted until you calculate the forward error, correction, bits and then sending the forward error correction bits. First and then the data is that part of the spec. That's uh adds that it adds latency.

J

I think there might be I'm not too sure to be honest, like there is use cases but yeah, I'm not sure. Okay, no problem, thank you I can I can. I can write this down late and see and look it up um later on.

B

Yeah any any sort of manipulation of the data you send out over a link, you always run into adding latency and that's a big trade-off with any sort of digital signal, processing or error. Correction coding is how much latency are you adding so so? Yes, it is a factor and the one of the things that we do in this particular implementation is to use the short codes in or a short frame instead of long in, in order to kind of address some some latency issues. uh So the.

D

B

Good, it's a it's something that you can't get away away from if you're, if you're doing any sort of manipulation or filtering or changing of your.

A

B

Of your your work, you know, then latency is always a factor. uh It's we try to reduce it wherever we can.

J

So in the spec itself I couldn't find latency like the word latency.

B

Right, it's implementation, specific you'll, you'll, you'll,.

J

A

B

You could you can implement all of this and have a lot of latency or you can do the sorts of things.

A

B

Do and and reduce it. So it's uh you.

A

B

Won't find it in this spec, you know, but there will be some in there.

E

I think the rationale for not really addressing latency in the ddb spec is probably because it's video broadcast and that's in that use case, the latency is not terribly important, but maybe in other cases it certainly most certainly is.

B

Yeah, that's a good.

E

J

Yeah yeah, I think you're.

C

B

B

All right, uh I think, let's uh we'll give the florida to thomas perry to talk about uh his advisory opinions today and uh but feel free every everyone else to ask questions and then we'll we'll close with a short discussion about plans for polar codes and the matlab workflow in remote labs. So thomas, you have the floor.

I

Yeah, okay, thanks, I don't have a lot to say, but um yeah I think maybe just worth mentioning that the great work that andre just showed um is the some really complex um encoding and I think um him and some other people in the team, um especially on chilo working towards trying to test this now over the air or over coax cables, um which would be a really really nice milestone to get to, um and I think, basically meets the first phase of phase four.

I

If that makes sense which, having the over-the-air transmission, um which is really nice, um we don't really have much mouth say off. Not do you have anything particularly thinking of michelle.

B

uh No I'd like to to um to highlight that that we we are moving as quickly as we can to to prove out all of our designs over the air. Our bias is that it doesn't work until it's transmitted over the air or, like you said, over coax, and fortunately we can. We can transmit over the air in remote labs and we're getting there.

B

The the basic idea here is to take our custom open source um ip blocks, the the encoder, for example, that has been discussed today and then graphed that in or include incorporate integrate that into the reference design from analog devices. The particular rfic that we're looking at using is the 9371.

B

The development board that we are using is the adrv 9371, and this fits onto a ultra scale. Xilinx fpga development board called the zc706, and these this equipment is available for for anyone. That wants to do this sort of work over the internet through remote labs at open research institute, and so that's what we're provided and what we're supporting and the the status right now is that we have made a whole lot of progress in incorporating and integrating the ip block into the reference design from from analog devices. We're not yet transmitting over the air.

B

We're working through lots of different scripting to properly integrate all of this work, and we anticipate being able to do this is over there as soon as possible. The first way that we tried to do it was to take the reference design and follow the how to integrate your ip core into our stuff from analog devices uh ran into a little bit of trouble there.

B

So so that's that's a that's one front of progress and then uh what uh swatu did is to start with his block and then to pull in the reference design, uh and we had some interesting tools. Issues with that vivado, which is the ide that we're using we used 2019.1, because that's the the latest released version for the reference design. So we've run into some interesting tools, issues problems, but every day you know these are the things that you have to deal with and solve for for sort of a complex ide, an ecosystem like this.

B

So we're looking forward to being able to transmit this over the air for being able to receive it. We do have some a set of commercial equipment for dbbs ii and we're we're going to sort of require uh any of our work to be received. You know demodulated, decoded and proved out.

B

You know, look at look at what you get on the other end using lab gear commercial lab gear. So if you want to learn more about that, it's those all the gear is listed on the remote labs section of the open research institute github. So when, when we publish this I'll, have the link directly to that.

B

If you want to look at all the different all the different equipment, so the goal is, of course, to have it over the air and then to start working on the adaptive coding and modulation side to start looking at what we need to do in order to make this resilient as possible for space.

B

What we need to do in order to make the system as resilient and useful as possible for terrestrial and those those may be two different things, uh and that's uh that's where we're at today, all right. um Any any questions for this particular part.

E

Is a question about what you just talked about possible right now, michelle.

B

Of course, please go ahead.

E

Great I'm interested in these projects for terrestrial use, um aerial drones, for example, and um and they can be sort of as the technology improves, their velocities will be increasing and there brings in doppler shifts, and you certainly have that with a satellite, but what is sort of um which is and you're going to be, I'm sure you're going to be resilient on with regards to doppler shift. The question I have is just the data rates that you're expecting and actually the use of the dvd for data.

E

I know some people have been using it, but it was really designed for digital video.

E

Is that uh a good use case for data? Just generic data.

B

Yes, uh actually dvb. The organization has a protocol that we're using called generic stream encapsulation or gse, and this is a drop-in replacement for um for mpeg, and so that's that's. Our eventual goal is to to use uh gse uh generic data. So what that gives you is a as it says, generic generic stream or generic data, and you get to you get back some of the overhead that you spend on broadcast mpeg stream and in terms of data rate, the data rate changes with respect to to what coding and modulation you do.

B

Our particular design for for space or for terrestrial uh use assumes up to 10 megahertz uh bandwidth yeah, and then you have your roll-off factor and all that, um but you can go narrower if you need to for maybe, if you're talking about drones, you may not want the whole 10 megahertz bandwidth, um you know, but you fix your symbol rate and then you vary your modulation and coding as needed in order to adapt to whatever path that you have.

B

You know whatever what your environment or what your channel is, or what your stations in your population of users have. Some people will have powerful stations. Some people will not. Some people will have a pointing error. You know microwave pointing is a you know. Some won't some are moving and some won't. um This particular set of protocols is resilient to doppler and is uh is good for that.

B

We ran through the numbers all the way up to leo um and then so I think mike parker was here a little earlier and he is using dbbs2 on cat sat uh 10, megahertz, 10 gigahertz uh down link in the amateur image part of the band um and is is doing so so we've been working and and collaborating with him over the past couple of years about that. So that's that's. A good uh proof. uh Application for for dvbs2 um on in space.

B

uh In a mission um so yeah you'll, you'll, see the data rate will change with respect to how much coding and what how complex the modulation can be. So the data rate will change around. So you can. You can go through the table and see like if you had very low signal-to-noise ratios situation.

B

Your data rate will be much lower, but you will be able to get through a surprisingly low s, r or all the way up to some some. If you have a booming signal, then you can take advantage of that.

E

Exactly then, the flip side of that, of course, is uh the latency. um Is that is that a is there a design goal for the latency that, uh if you wanted to do real-time control of the satellite, let's say: would that be possible?.

B

Yeah traditionally, the control part of the satellite would be outside of the traffic band, but we've actually talked about including it. So, yes, the the you would as soon as you have a um an implementation that you can start testing, um then you start looking at things like like latency and timing and and all of that so so yeah. That's that's. Definitely on the docket.

B

Okay, great thanks michelle, of course, all right. Any other questions on this particular part.

B

Okay and then the final thing is that we have a zcu 106 ultra scale board, and this is probably where we're going to focus the polar coding uh part of the project, and we have we've gone ahead and purchased a license for matlab now.

B

What we have been using for for matlab is the home license, which is 150, is an excellent deal, but it does not include hdl coder or gpu coder or matlab coder and those are the heterogeneous processing types of toolboxes, um and so there's a couple of things that I'm sure a lot of you are thinking. It's like well, why in the world, would you go with matlab and not an open source tool flow, because octave is wonderful?

B

There isn't really a replacement for simulink and some of the things that we want to do don't exist in the open source tool flow. Yet so there's a two-pronged approach here. This is to allow open source work and polar coding to happen, and we do need to meet the people that are that are producing this work at universities and and at some companies that actually want to participate in open source work. They need to kind of meet them where they're at so that's one reason.

B

Another big reason is that the both the xilinx and companies like analog devices, assume that you're using matlab and they have a lot of things bolted up to matlab. That may be there's more of a gap between that and octave.

B

um So so meeting where people are at and using the right tool for the job with a lot of quotes. Heavy quotes around that is, is what we do being able to then quantify what it is about. Matlab that people like uh what it. What is it?

B

What does it allow you to do and then take that over to the open source tools, community and say: okay, here's areas where we probably need to to focus more on the tool making side, since our core point is developing communications, advanced communications, algorithms and and designs and hardware for for open source.

B

Our our core point of existing is not to develop octave. However, as an open source project, I think it's incumbent upon us to find out what those tools need to do in order to bolt up to current modern parts, and so since polar codes really ought to be something that that we as open source and amateur communities, should you we should be able to to participate, use, learn and know about as much as possible. That is why this we're doing this particular area of research and development.

B

There are some, in addition to all of the things that I just said, tools, issues and you know using proprietary tools in order to make a open source stuff happen. There is another big issue with polar codes, and that is patents, so polar codes were picked and are used and exploited in 5g and there's a whole ton of sub patents.

B

So this is an area where we are going to spend some time and effort to work out a way forward for open source, polar codes uh to be developed, so so getting the the technical side of the house and the resources at remote lab in line. um That's one part of the the problem you know being able to quantify what what open source tools need to do in order to to fill in this area and to do this sort of thing is another, and then the regulatory and legal side is a third.

B

So if you're interested in this sort of work, uh please let us know and um welcome, aboard and we'll we'll see what we can do we're going to give ourselves a deadline of roughly a year from this week, uh we're in the startup program by matlab. So we were accepted, open research institute was was accepted into the program, and that gives us an enormous discount on the the sorts of toolboxes that were not available that are simply not available to the home license.

B

So we figure we'll give it a good hard shot for the next year and then publish what we find or publish along going all along the way, but to to do a final report a year from now and then um assess whether or not we want to spend the roughly thirty six hundred dollars to get all of these matlab tools again or not. So that's the that's the plan for the polar code.

B

uh The polar coding stuff is not going to compete with the ldpc or p4dx or any uh of the or the m17 fpga work which we didn't discuss today, but is actually on the you know on the docket on the deck as well. So that's a zc706 board and the zcu 106 is where we're looking at doing polar coding and if we need to change that, we we will but the the goal.

B

Another uh aspect of this was not to to compete with the relatively busy uh zc706 board, where people are doing the ldpc, encoder and eventually the ldbc receiver, and so that's uh that's it from the polar code side, all right. So any final questions, comments or advice.

I

I said I'm sure you thought about this. I was curious. um A matlab of math works, okay with you pub or us publishing the results, hdl hdl coder openly, because sometimes companies can get a bit funny about that kind of stuff.

B

From a initial read through of all of the agreements, no that you are good to to publish the um the eventual work right, so you get an hdl output and then that's not really where we we're going to end things. That's just what we take and- and we will have to do a lot of work from there um so so we'll have to. We may run into more trouble uh with the with the fact that we're we're publishing polar code stuff rather than matlab stuff. But it's a good question.

B

I didn't see anything in any of the paperwork or the or the uh the startup agreement, um but it's a good thing to double check so I'll. Take it as an action item and go back through and carefully make sure that we're we're not getting into anything too tricky.

D

All right, cool.

E

Michelle question on the polar codes patent exclusions, the usually at companies that are patenting codes like this. They try to be very broad in their scope, is: has anybody identified a path that would allow the open source polar codes development to to be successful, or is this still half does that path still have to be found.

B

I think both so we we know that we, um based on the discussion at the very very beginning um right before we started uh paul- and I kb5 mu, were talking about this and the general approach for something like this is to to go back 20 years and define and only use things that are cited back 20 years now for polar.

G

B

I think you can imagine that that might be challenging um and and then also to look at to look at the ecosystem and see, like you know, look at all of the things that all the work that is going on and and to seek uh some some solid legal advice and only use publish as we go to put everything out there and and- and you know so so both and really is the you know.

B

Yes, there is a general approach that which may or may not be possible because I haven't looked to see if there's anything, that's 20 years or older and then also to just get some good advice, and since there is a lot of activity in academia on polar codes, there's a lot that's published. That's uh you know that we can. We can cite, um but this is going to be um high wire sort of it's.

B

uh You know things worth doing are really easy, and this is definitely not an easy thing to do, because it's uh it's not just a difficult technically and rewarding technically, um but it's also uh very much a patent encumbered area. So we have lots of work here to do over the next year.

E

Well, look uh I wish you.

A

B

Take all good wishes that we can get and we'll.

H

B

It a good hard uh hit and, um and then we'll publish everything. You know that we that we find that you know if it's a if it turns out to be absolutely insurmountable, then we'll describe exactly how why.

E

B

So and then you know, maybe uh we can from there you know it could there can be um future work so sure good. Thank you. Michelle you're welcome.

K

I have a question for the group.

E

K

uh From the remote lab point of view, we'll be soon installing these matlab tools onto a virtual machine for people to use, and it's unclear to me whether it's desirable to have it on its own separate virtual machine. So it doesn't interfere at all with fpga development on hardware or whether it needs to be on the same virtual machine with the cc set uh 106..

K

So any opinions or experience on that would be welcome here.

B

I don't know yet. My instinct is that the the matlab toolboxes are going to need to interact with vivado, and my gut instinct was that we should install matlab on karapi, which is the virtual machine that is currently connected up to and runs the zc106.

B

We do have access to technical support um which you we haven't up until now, using the the home license.

B

So this might be something that we go ahead and try and do a couple of hello world uh simple examples that are that are built in to um built into the matlab toolboxes that we want to use and then see what happens. And then, if it blows up or we have significant problems, then we go to technical support and ask them how they view this, this installation or this setup to be so that was my general hot, very high level sort of approach to this.

B

Also, I have a couple of people at universities to ask. I know that universities install you, know an educational license in matlab and are doing similar things to what we want to do. So we we should, within the community, be able to ask for some advice and and help on. You know: hey gee, how do you, how do you set this up to where it'll work with with hardware um and then the related tools that are that are needed along the way.

K

Okay, if nobody else has any thoughts on that subject, we'll try to do it one way or the other and see how it works out.

J

Yeah, I I think would like we need people using to see like I don't have um the the vision or you know. I don't understand enough about how matlab interacts to to be able to tell now.

B

Yeah I mean either I've only I've only.

I

Used it on individual.

B

Computers- but you know I'm I'm pretty- this is we'll be able to figure it out and we'll do whatever.

A

B

To get it to work, I'm I'm assuming that what we will be able to pull it off and get it uh probably has to be on the vm may have to be some sort of tailored installation and we'll we do have um access to to some customer support and some technical support. So I'm I'm optimistic. I think it'll work out, yeah yeah.

J

Yeah in some way or another.

B

Exactly some way or another cool, okay, any any last questions or advice.

E

uh This is daniel again. One more question is: when should when, when will the next presentation like this one take place.

B

I would defer to thomas perry, since um the quarterly technical advisory committee is is, uh is his uh initiative and I would defer to him on it, but we'll probably have it in a quarter. I think what do you think thomas.

I

Yeah yeah, that makes sense. I don't know about the exact um dates or anything, but yeah roughly a quarter would stick with the naming convention.

B

Yeah yeah at least once a quarter, but we also do have. um We have focused meetings like for the fpga team, uh that's weekly on tuesdays and we also try to do office hours. um So I I try to do them and a couple of other people try to do them so so this you won't have to wait a quarter, but definitely this this type of meeting uh will happen in another quarter, but for office hours. Just look!

B

uh If you're not already on the mailing list for open research institute for the face for ground team, then that's that's our main announcement list and if you're on slack, then the uh the office hours get posted there. So so that's the advice. I have.

E

Thank you. Michelle.

B

Yeah sure thing: okay, thank you, everybody! We will close here at uh it's noon my time and we will edit and post this recording as soon as we can. If all goes well, it might be today and there will also be some materials and some slides um from throughout the day. Those materials will also be made available. So uh we'll we'll post an announcement about that everywhere. We usually post things like on twitter and our our slack and our our mailing list.

B

So thank you again and I will close the meeting and see you next time.

A