[Music]

Herald: Has anyone in here ever worked
with libusb or PI USB? Hands up. Okay. Who

also thinks USB is a pain? <i>laughs</i> Okay.
Sergey and Alexander were here back in at

the 26C3, that's a long time ago. I think
it was back in Berlin, and back then they

presented their first homemade, or not
homemade, SDR, software-defined radio.

This year they are back again and they
want to show us how they implemented

another one, using an FPGA, and to
communicate with it they used PCI Express.

So I think if you thought USB was a pain,
let's see what they can tell us about PCI

Express. A warm round of applause for
Alexander and Sergey for building a high

throughput, low latency, PCIe-based
software-defined radio

[Applause]
Alexander Chemeris: Hi everyone, good

morning, and welcome to the first day of
the Congress. So, just a little bit

background about what we've done
previously and why we are doing what we

are doing right now, is that we started
working with software-defined radios and

by the way, who knows what software
defined radio is? Okay, perfect. <i>laughs</i>

And who ever actually used a software-
defined radio? RTL-SDR or...? Okay, less

people but that's still quite a lot. Okay,
good. I wonder whether anyone here used

more expensive radios like USRPs? Less
people, but okay, good. Cool. So before

2008 I've had no idea what software-
defined radio is, was working with voice

over IP software person, etc., etc., so I
in 2008 I heard about OpenBTS, got

introduced to software-defined radio and I
wanted to make it really work and that's

what led us to today. In 2009 we had to
develop a clock tamer. A hardware which

allows to use, allowed to use USRP1 to run GSM
without problems. If anyone ever tried

doing this without a good clock source
knows what I'm talking about. And we

presented this - it wasn't an SDR it was
just a clock source - we presented this in

2009 in 26C3.
Then I realized that using USRP1 is not

really a good idea, because we wanted to
build a robust, industrial-grade base

stations. So we started developing our own
software defined radio, which we call

UmTRX and it was in - we started started
this in 2011. Our first base stations with

it were deployed in 2013, but I always
wanted to have something really small and

really inexpensive and back then it wasn't
possible. My original idea in 2011, we

were to build a PCI Express card. Mini,
sorry, not PCI Express card but mini PCI

card.
If you remember there were like all the

Wi-Fi cards and mini PCI form factor and I
thought that would be really cool to have

an SDR and mini PCI, so I can plug this
into my laptop or in some embedded PC and

have a nice SDR equipment, but back then
it just was not really possible, because

electronics were bigger and more power
hungry and just didn't work that way, so

we designed UmTRX to work over gigabit
ethernet and it was about that size. So

now we spend this year at designing
something, which really brings me to what

I wanted those years ago, so the XTRX is a
mini PCI Express - again there was no PCI

Express back then, so now it's mini PCI
Express, which is even smaller than PCI, I

mean mini PCI and it's built to be
embedded friendly, so you can plug this

into a single board computer, embedded
single board computer. If you have a

laptop with a mini PCI Express you can
plug this into your laptop and you have a

really small, software-defined radio
equipment. And we really want to make it

inexpensive, that's why I was asking how
many of you have ever worked it with RTL-

SDR, how many of you ever worked with you
USRPs, because the gap between them is

pretty big and we want to really bring the
software-defined radio to masses.

Definitely won't be as cheap as RTL-SDR,
but we try to make it as close as

possible.
And at the same time, so at the size of

RTL-SDR, at the price well higher but,
hopeful hopefully it will be affordable to

pretty much everyone, we really want to
bring high performance into your hands.

And by high performance I mean this is a
full transmit/receive with two channels

transmit, two channels receive, which is
usually called 2x2 MIMO in in the radio

world. The goal was to bring it to 160
megasamples per second, which can roughly

give you like 120 MHz of radio spectrum
available.

So what we were able to achieve is, again
this is mini PCI Express form factor, it

has small Artix7, that's the smallest and
most inexpensive FPGA, which has ability

to work with a PCI Express. It has LMS7000
chip for RFIC, very high performance, very

tightly embedded chip with even a DSP
blocks inside. It has even a GPS chip

here, you can actually on the right upper
side, you can see a GPS chip, so you can

accually synchronize your SDR to GPS for
perfect clock stability,

so you won't have any problems running any
telecommunication systems like GSM, 3G, 4G

due to clock problems, and it also has
interface for SIM cards, so you can

actually create a software-defined radio
modem and run other open source projects

to build one in a four LT called SRSUI, if
you're interested, etc., etc. so really

really tightly packed one. And if you put
this into perspective: that's how it all

started in 2006 and that's what you have
ten years later. It's pretty impressive.

<i>applause </i>
Thanks. But I think it actually applies to

the whole industry who is working on
shrinking the sizes because we just put

stuff on the PCB, you know. We're not
building the silicon itself. Interesting

thing is that we did the first approach:
we said let's pack everything, let's do a

very tight PCB design. We did an eight
layer PCB design and when we send it to a

fab to estimate the cost it turned out
it's $15,000 US per piece. Well in small

volumes obviously but still a little bit
too much. So we had to redesign this and

the first thing which we did is we still
kept eight layers, because in our

experience number of layers nowadays have
only minimal impact on the cost of the

device. So like six, eight layers - the
price difference is not so big. But we did

complete rerouting and only kept 2-Deep
MicroVIAs and never use the buried VIAs.

So this make it much easier and much
faster for the fab to manufacture it and

the price suddenly went five, six times
down and in volume again it will be

significantly cheaper. And that's just for
geek porn how PCB looks inside. So now

let's go into real stuff. So PCI Express:
why did we choose PCI Express? As it was

said USB is a pain in the ass. You can't
really use USB in industrial systems. For

a whole variety of reasons just unstable.
So we did use Ethernet for many years

successfully but Ethernet has one problem:
first of all inexpensive Ethernet is only

one gigabit and one gigabit does not offer
you enough bandwidth to carry all the data

we want, plus its power-hungry etc. etc.
So PCI Express is really a good choice

because it's low power, it has low
latency, it has very high bandwidth and

it's available almost universally. When we
started looking into this we realize that

even ARM boards, some of ARM boards have
PCI Express, mini PCI Express slots, which

was a big surprise for me for example.
So the problems is that unlike USB you do

need to write your own kernel driver for
this and there's no way around. And it is

really hard to write this driver
universally so we are writing it obviously

for Linux because they're working with
embedded systems, but if we want to

rewrite it for Windows or for macOS we'll
have to do a lot of rewriting. So we focus

on what we want on Linux only right now.
And now the hardest part: debugging is

really non-trivial. One small error and
your PC is completely hanged because you

use something wrong. And you have to
reboot it and restart it. That's like

debugging kernel but sometimes even
harder. To make it worse there is no

really easy-to-use plug-and-play
interface. If you want to restart;

normally, when you when you develop a PCI
Express card, when you want when you want

to restart it you have to restart your
development machine. Again not a nice way,

it's really hard. So the first thing we
did is we found, that we can use

Thunderbolt 3 which is just recently
released, and it has ability to work

directly with PCI Express bus. So it
basically has a mode in which it converts

a PCI Express into plug-and-play
interface. So if you have a laptop which

supports Thunderbolt 3 then you can use
this to do plug and play your - plug or

unplug your device to make your
development easier. There are always

problems: there's no easy way, there's no
documentation. Thunderbolt is not

compatible with Thunderbolt. Thunderbold 3
is not compatible with Thunderbold 2.

So we had to buy a special laptop with
Thunderbold 3 with special cables like all

this all this hard stuff. And if you
really want to get documentation you have

to sign NDA and send a business plan to
them so they can approve that your

business makes sense.
<i>laughter</i>

I mean... <i>laughs</i> So we actually opted
out. We set not to go through this, what

we did is we found that someone is
actually making PCI Express to Thunderbolt

3 converters and selling them as dev
boards and that was a big relief because

it saved us lots of time, lots of money.
You just order it from from some from some

Asian company. And yeah this is how it
looks like this converter. So you buy it,

like several pieces you can plug in your
PCI Express card there and you plug this

into your laptop. And this is the with
XTRX already plugged into it. Now the only

problem we found is that typically UEFI
has a security control enabled, so that

any random thunderbold device can't hijack
your PCI bus and can't get access to your

kernel memory and do some bad stuff. Which
is a good idea - the only problem is that

there is, it's not fully implemented in
Linux. So under Windows if you plug in a

device which is which has no security
features, which is not certified, it will

politely ask you like: "Do you really
trust this device? Do you want to use it?"

you can say "yes". Under Linux it just
does not work. <i>laughs</i> So we spend some

time trying to figure out how to get
around this. Right, some patches from

Intel which are not mainline and we were
not able to actually get them work. So we

just had to disable all this security
measure in the laptop. So be aware that

this is the case and we suspect that happy
users of Apple might not be able to do

this because Apple don't have BIOS so it
probably can't disable this feature. So

probably good incentive for someone to
actually finish writing the driver.

So now to the goal: so we wanted to, we
want to achieve 160 mega samples per

second, 2x2 MIMO, which means two
transceiver, two transmit, two receive

channels at 12 bits, which is roughly 7.5
Gbit/s. So first result when we plug this

when we got this board on the fab it
didn't work

Sergey Kostanbaev mumbles: as expected
Alexander Chemeris: yes as expected so the

first the interesting thing we realized is
that: first of all the FPGA has Hardware

blocks for talking to a PCI Express which
was called GTP which basically implement

like a PCI Express serial physical layer
but the thing is the numbering is reversed

in the in PCI Express in FPGA and we did
not realize this so we had to do very very

fine soldiering to actually swap the
<i>laughs</i> swap the lanes you can see this

very fine work there.
We also found that one of the components

was deadbug which is a well-known term for
chips which design stage are placed at

mirrored so we mirrored occasionally
mirrored that they pin out so we had to

solder it upside down and if you can
realize how small it is you can also

appreciate the work done. And what's funny
when I was looking at dead bugs I actually

found a manual from NASA which describes
how to properly soldier dead bugs to get

it approved.
<i>audience laughs</i>

So this is the link I think you can go
there and enjoy it's also fun stuff there.

So after fixing all of this our next
attempt this kind of works. So next stage

is debugging the FPGA code, which has to
talk to PCI Express and PCI Express has to

talk to Linux kernel and the kernel has to
talk to the driver, driver has talked to

the user space. So peripherals are easy so
the UART SPIs we've got to work almost

immediately no problems with that, but DMA
was a real beast. So we spent a lot of

time trying to get DMA to work and the
problem is that with DMA it's on FPGA so

you can't just place a breakpoint like you
do in C or C++ or in other languages it's

real-time system running on system like
it's real-time hardware, which is running

on the fabric so you we had to Sergey was
mainly developing this had to write a lot

of small test benches and and test
everything piece by piece.

So all parts of the DMA code we had was
wrapped into a small test bench which was

emulating all the all the tricks and as
classics predicted it took about five to

ten times more than actually writing the
code. So we really blew up our and

predicted timelines by doing this, but the
end we've got really stable stable work.

So some suggestions for anyone who will
try to repeat this exercise is there is a

logic analyzer built-in to Xilinx and you
can use, it it's nice it's, sometimes it's

very helpful but you can't debug
transient box, which are coming out at

when some weird conditions are coming up.
So you have to implement some read back

registers which shows important statistic
like important data about how your system

behaves, in our case it's various counters
on the DMA interface. So you can actually

see kind of see what's happening with your
with your data: Is it received? Is it

sent? How much is and how much is
received? So like for example, we can see

when we saturate the bus or when actually
is an underrun so host is not providing

data fast enough, so we can at least
understand whether it's a host problem or

whether it's an FPGA, problem on which
part we do we debug next because again:

it's a very multi layer problem you start
with FPGA, PCI Express, kernel, driver,

user space, and any part can fail. so you
can't work blind like this. So again the

goal was to get 160 MSPS with the first
implementation we could 2 MSPS: roughly 60

times slower.
The problem is that software just wasn't

keeping up and wasn't sending data fast
enough. So it was like many things done

but the most important parts is: use real-
time priority if you want to get very

stable results and well fix software bugs.
And one of the most important bugs we had

was that DMA buffers were not freed in
proper time immediately so they were busy

for longer than they should be, which
introduced extra cycles and basically just

reduced the bandwidth.
At this point let's talk a little bit

about how to implement a high-performance
driver for Linux, because if you want to

get real real performance you have to
start with the right design. There are

basically three approaches and the whole
spectrum in between; like two approaches

and the whole spectrum in between, which
is where you can refer to three. The first

approach is full kernel control, in which
case kernel driver not only is on the

transfer, it actually has all the logics
of controlling your device and all the

export ioctl to the user space and
that's the kind of a traditional way of

writing drivers. Your your user space is
completely abstracted from all the

details. The problem is that this is
probably the slowest way to do it. The

other way is what's called the "zero cup
interface": your only control is held in

the kernel and data is provided, the raw
data is provided to user space "as-is". So

you avoid memory copy which make it
faster. But still not fast enough if you

really want to achieve maximum
performance, because you still have

context switches between the kernel and
the user space. The most... the fastest

approach possible is to have full user
space implementation when kernel just

exposed everything and says "now you do it
yourself" and you have no you have no

context switches, like almost no, and you
can really optimize everything. So what

is... what are the problems with this?
The pro the pros I already mentioned: no

no switches between kernel user space,
it's very low latency because of this as

well, it's very high bandwidth. But if you
are not interested in getting the very

high performance, the most performance, and
you just want to have like some little,

like say low bandwidth performance, then
you will have to add hacks, because you

can't get notifications of the kernel that
resources available is more data

available. It also makes it vulnerable
vulnerable because if user space can

access it, then it can do whatever it
want. We at the end decided that... one

more important thing: how to actually to
get the best performance out of out of the

bus. This is a very (?)(?) set as we want
to poll your device or not to poll and get

notified. What is polling? I guess
everyone as programmer understands it, so

polling is when you asked repeatedly: "Are
you ready?", "Are you ready?", "Are you

ready?" and when it's ready you get the
data immediately.

It's basically a busy loop of your you
just constantly asking device what's

happening. You need to dedicate a full
core, and thanks God we have multi-core

CPUs nowadays, so you can dedicate the
full core to this polling and you can just

pull constantly. But again if you don't
need this highest performance, you just

need to get something, then you will be
wasting a lot of CPU resources. At the end

we decided to do a combined architecture
of your, it is possible to pull but

there's also a chance and to get
notification from a kernel to for for

applications, which recover, which needs
low bandwidth, but also require a better

CPU performance. Which I think is the best
way if you are trying to target both

worlds. Very quickly: the architecture of
system. We try to make it very very

portable so and flexible. There is a
kernel driver, which talks to low-level

library which implements all this logic,
which we took out of the driver: to

control the
PCI Express, to work with DMA, to provide

all the... to hide all the details of the
actual bus implementation.

And then there is a high-level library
which talks to this low-level library and

also to libraries which implement control
of actual peripherals, and most

importantly to the library which
implements control over our RFIC chip.

This way it's very modular, we can replace
PCI Express with something else later, we

might be able to port it to other
operating systems, and that's the goal.

Another interesting issue is: when you
start writing the Linux kernel driver you

very quickly realize that while LDD, which
is a classic book for a Linux driver,

writing is good and it will give you a
good insight; it's not actually up-to-

date. It's more than ten years old and
there's all of new interfaces which are

not described there, so you have to resort
to reading the manuals and all the

documentation in the kernel itself. Well
at least you get the up-to-date

information. The decisions we made is to
make everything easy. We use TTY for GPS

and so you can really attach a pretty much
any application which talks to GPS. So all

of existing applications can just work out
of the box. And we also wanted to be able

to synchronize system clock to GPS, so we
get automatic log synchronization across

multiple systems, which is very important
when we are deploying many, many devices

around the world.
We plan to do two interfaces, one as key

PPS and another is a DCT, because DCT line
on the UART exposed over TTY. Because

again we found that there are two types of
applications: one to support one API,

others that support other API and there is
no common thing so we have to support

both. As we described, we want to have
polls so we can get notifications of the

kernel when data is available and we don't
need to do real busy looping all the time.

After all the software optimizations we've
got to like 10 MSPS: still very, very far

from what we want to achieve.
Now there should have been a lot of

explanations about PCI Express, but when
we actually wrote everything we wanted to

say we realize, it's just like a full two
hours talk just on PCI Express. So we are

not going to give it here, I'll just give
some highlights which are most

interesting. If you if there is real
interest, we can set up a workshop and

some of the later days and talking more
details about PCI Express specifically.

The thing is there is no open source cores
for PCI Express, which are optimized for

high performance, real time applications.
There is Xillybus which as I understand is

going to be open source, but they provide
you a source if you pay them. It's very

popular because it's very very easy to do,
but it's not giving you performance. If I

remember correctly the best it can do is
maybe like 50 percent bus saturation.

So there's also Xilinx implementation, but
if you are using Xilinx implementation

with AXI bus than you're really locked in
with AXI bus with Xilinx. And it also not

very efficient in terms of resources and
if you remember we want to make this very,

very inexpensive. So our goal is to you
... is to be able to fit everything in the

smallest Arctic's 7 FPGA, and that's quite
challenging with all the stuff in there

and we just can't waste resources. So
decision is to write your own PCI Express

implementation. That's how it looks like.
I'm not going to discuss it right now.

There are several iterations. Initially it
looked much simpler, turned out not to

work well.
So some interesting stuff about PCI

Express which we stumbled upon is that it
was working really well on Atom which is

our main development platform because we
are doing a lot of embedded stuff. Worked

really well. When we try to plug this into
core i7 just started hanging once in a

while. So after like several not days
maybe with debugging, Sergey found that

very interesting statement in the standard
which says that value is zero in byte

count actually stands not for zero bytes
but for 4096 bytes.

I mean that's a really cool optimization.
So another thing is completion which is a

term in PCI Express basically for
acknowledgment which also can carry some

data back to your request. And sometimes
if you're not sending completion, device

just hangs. And what happens is that in
this case due to some historical heritage

of x86 it just starts returning you FFF.
And if you have a register which says: „Is

your device okay?“ and this register shows
one to say „The device is okay“, guess

what will happen?
You will be always reading that your

device is okay. So the suggestion is not
to use one as the status for okay and use

either zero or better like a two-beat
sequence. So you are definitely sure that

you are okay and not getting FFF's. So
when you have a device which again may

fail at any of the layers, you just got
this new board, it's really hard, it's

really hard to debug because of memory
corruption. So we had a software bug and

it was writing DMA addresses
incorrectly and we were wondering why we

are not getting any data in our buffers at
the same time. After several starts,

operating system just crashes. Well, that's
the reason why there is this UEFI

protection which prevents you from
plugging in devices like this into your

computer. Because it was basically writing
data, like random data into random

portions of your memory. So a lot of
debugging, a lot of tests and test benches

and we were able to find this. And another
thing is if you deinitialize your driver

incorrectly, and that's what's happening
when you have plug-and-play device, which

you can plug and unplug, then you may end
up in a situation of your ... you are

trying to write into memory which is
already freed by approaching system and

used for something else. Very well-known
problem but it also happens here. So there

... why DMA is really hard is because it
has this completion architecture for

writing for ... sorry ... for reading
data. Writes are easy. You just send the

data, you forget about it. It's a fire-
and-forget system. But for reading you

really need to get your data back. And the
thing is, it looks like this. You really

hope that there would be some pointing
device here. But basically on the top left

you can see requests for read and on the
right you can see completion transactions.

So basically each transaction can be and
most likely will be split into multiple

transactions. So first of all you have to
collect all these pieces and like write

them into proper parts of the memory.
But that's not all. The thing is the

latency between request and completion is
really high. It's like 50 cycles. So if

you have a single, only single transaction
in fly you will get really bad

performance. You do need to have multiple
transactions in flight. And the worst

thing is that transactions can return data
in random order. So it's a much more

complicated state machine than we expected
originally. So when I said, you know, the

architecture was much simpler originally,
we don't have all of this and we had to

realize this while implementing. So again
here was a whole description of how

exactly this works. But not this time. So
now after all these optimizations we've

got 20 mega samples per second which is
just six times lower than what we are

aiming at. So now the next thing is PCI
Express lanes scalability. So PCI Express

is a serial bus. So it has multiple lanes
and they allow you to basically

horizontally scale your bandwidth. One
lane is like x, than two lane is 2x, four

lane is 4x. So the more lanes you have the
more performance you are getting out of

your, out of your bus. So the more
bandwidth you're getting out of your bus.

Not performance. So the issue is that
typical a mini PCI Express, so the mini

PCI Express standard only standardized one
lane. And second lane is left as optional.

So most motherboards don't support this.
There are some but not all of them. And we

really wanted to get this done. So we
designed a special converter board which

allows you to plug your mini PCI Express
into a full-size PCI Express and

get two lanes working. And we're also
planning to have a similar board which

will have multiple slots so you will be
able to get multiple XTRX-SDRs on to the

same, onto the same carrier board and plug
this into let's say PCI Express 16x and

you will get like really a lot of ... SDR
... a lot of IQ data which then will be

your problem how to, how to process. So
with two x's it's about twice performance

so we are getting fifty mega samples per
second. And that's the time to really cut

the fat because the real sample size of
LMS7 is 12 bits and we are transmitting 16

because it's easier. Because CPU is
working on 8, 16, 32. So we originally

designed the driver to support 8 bit, 12
bit and 16 bit to be able to do this

scaling. And for the test we said okay
let's go from 16 to 8 bit. We'll lose

some dynamic range but who cares these
days. Still stayed the same, it's still 50

mega samples per second, no matter what we
did. And that was a lot of interesting

debugging going on. And we realized that
we actually made another, not a really

mistake. We didn't, we didn't really know
this when we designed. But we should have

used a higher voltage for this high speed
bus to get it to the full performance. And

at 1.8 it was just degrading too fast and
the bus itself was not performing well. So

our next prototype will be using higher
voltage specifically for this bus. And

this is kind of stuff which makes
designing hardware for high speed really

hard because you have to care about
coherence of the parallel buses on your,

on your system. So at the same time we do
want to keep 1.8 volts for everything else

as much as possible. Because another
problem we are facing with this device is

that by the standard mini PCI Express
allows only like ...

Sergey Kostanbaev: ... 2.5 ...
Alexander Chemeris: ... 2.5 watts of power

consumption, no more. And that's we were,
we were very lucky that LMS7 has such so

good, so good power consumption
performance. We actually had some extra

space to have FPGA and GPS and all this
stuff. But we just can't let the power

consumption go up. Our measurements on
this device showed about ...

Sergey Kostanbaev: ... 2.3 ...
Alexander Chemeris: ... 2.3 watts of power

consumption. So we are like at the limit
at this point. So when we fix the bus with

the higher voltage, you know it's a
theoretical exercise, because we haven't

done this yet, that's plenty to happen in
a couple months. We should be able to get

to this numbers which was just 1.2 times
slower. Then the next thing will be to fix

another issue which we made at the very
beginning: we have procured a wrong chip.

Just one digit difference, you can see
it's highlighted in red and green, and

this chip it supports only a generation 1
PCI Express which is twice slower than

generation 2 PCI Express.
So again, hopefully we'll replace the chip

and just get very simple doubling of the
performance. Still it will be slower than

we wanted it to be and here is what comes
like practical versus theoretical numbers.

Well as every bus it has it has overheads
and one of the things which again we

realized when we were implementing this
is, that even though the standard

standardized is the payload size of 4kB,
actual implementations are different. For

example desktop computers like Intel Core
or Intel Atom they only have 128 byte

payload. So there is much more overhead
going on the bus to transfer data and even

theoretically you can only achieve 87%
efficiency. And on Xeon we tested and we

found that they're using 256 payload size
and this can give you like a 92%

efficiency on the bus and this is before
the overhead so the real reality is even

worse. An interesting thing which we also
did not expect, is that we originally were

developing on Intel Atom and everything
was working great. When we plug this into

laptop like Core i7 multi-core really
powerful device, we didn't expect that it

wouldn't work. Obviously Core i7 should
work better than Atom: no, not always.

The thing is, we were plugging into a
laptop, which had a built-in video card

which was sitting on the same PCI bus and
probably manufacturer hard-coded the higher

priority for the video card than for
everything else in the system, because I

don't want your your screen to flicker.
And so when you move a window you actually

see the late packets coming to your PCI
device. We had to introduce a jitter

buffer and add more FIFO into the device
to smooth it out. On the other hand the

Xeon is performing really well. So it's
very optimized. That said, we have tested

it with discreet card and it outperforms
everything by whooping five seven percent.

What you get four for the price. So this
is actually the end of the presentation.

We still have not scheduled any workshop,
but if there if there is any interest in

actually seeing the device working or if
you interested in learning more about the

PCI Express in details let us know we'll
schedule something in the next few days.

That's the end, I think we can proceed
with questions if there are any.

<i>Applause</i>
Herald: Okay, thank you very much. If you

are leaving now: please try to leave
quietly because we might have some

questions and you want to hear them. If
you have questions please line up right

behind the microphones and I think we'll
just wait because we don't have anything

from the signal angel. However, if you are
watching on stream you can hop into the

channels and over social media to ask
questions and they will be answered,

hopefully. So on that microphone.
Question 1: What's the minimum and maximum

frequency of the card?
Alexander Chemeris: You mean RF

frequency?
Question 1: No, the minimum frequency you

can sample at. the most SDR devices can
only sample at over 50 MHz. Is there a

similar limitation at your card?
Alexander Chemeris: Yeah, so if you're

talking about RF frequency it can go
from like almost zero even though that

works worse below 50MHz and all the way to
3.8GHz if I remember correctly. And in

terms of the sample rate right now it
works from like about 2 MSPS and to about

50 right now. But again, we're planning to
get it to these numbers we quoted.

Herald: Okay. The microphone over there.
Question 2: Thanks for your talk. Did you

manage to put your Linux kernel driver to
the main line?

Alexander Chemeris: No, not yet. I mean,
it's not even like fully published. So I

did not say in the beginning, sorry for
this. We only just manufactured the first

prototype, which we debugged heavily. So
we are only planning to manufacture the

second prototype with all these fixes and
then we will release, like, the kernel

driver and everything. And maybe we'll try
or maybe won't try, haven't decided yet.

Question 2: Thanks
Herald: Okay...

Alexander Chemeris: and that will be the
whole other experience.

Herald: Okay, over there.
Question 3: Hey, looks like you went

through some incredible amounts of pain to
make this work. So, I was wondering,

aren't there any simulators at least for
parts of the system, or the PCIe bus for

the DMA something? Any simulator so that
you can actually first design the system

there and debug it more easily?
Sergey Kostanbaev: Yes, there are

available simulators, but the problem's
all there are non-free. So you have to pay

for them. So yeah and we choose the hard
way.

Question 3: Okay thanks.
Herald: We have a question from the signal

angel.
Question 4: Yeah are the FPGA codes, Linux

driver, and library code, and the design
project files public and if so, did they

post them yet? They can't find them on
xtrx.io.

Alexander Chemeris: Yeah, so they're not
published yet. As I said, we haven't

released them. So, the drivers and
libraries will definitely be available,

FPGA code... We are considering this
probably also will be available in open

source. But we will publish them together
with the public announcement of the

device.
Herald: Ok, that microphone.

Question 5: Yes. Did you guys see any
signal integrity issues between on the PCI

bus, or on this bus to the LMS chip, the
Lime microchip, I think, this doing

the RF ?
AC: Right.

Question 5: Did you try to measure signal
integrity issues, or... because there were

some reliability issues, right?
AC: Yeah, we actually... so, PCI. With PCI

we never had issues, if I remember
correctly.

SK: No.
AC: I just... it was just working.

SK: Well, the board is so small, and when
there are small traces there's no problem

in signal integrity. So it's actually
saved us.

AC: Yeah. Designing a small board is easier.
Yeah, with the LMS 7, the problem is not

the signal integrity in terms of
difference in the length of the traces,

but rather the fact that the signal
degrades over voltage, also over speed in

terms of voltage, and drops below the
detection level, and all this stuff. We

use some measurements. I actually wanted
to add some pictures here, but decided

that's not going to be super interesting.
H: Okay. Microphone over there.

Question 6: Yes. Thanks for the talk. How
much work would it be to convert the two

by two SDR into an 8-input logic analyzer
in terms of hard- and software? So, if you

have a really fast logic analyzer, where
you can record unlimited traces with?

AC: A logic analyzer...
Q6: So basically it's just also an analog

digital converter and you largely want
fast sampling and a large amount of memory

to store the traces.
AC: Well, I just think it's not the best

use for it. It's probably... I don't know.
Maybe Sergey has any ideas, but I think it

just may be easier to get high-speed ADC
and replace the Lime chip with a high-

speed ADC to get what you want, because
the Lime chip has so many things there

specifically for RF.
SK: Yeah, the main problem you cannot just

sample original data. You should shift it
over frequency, so you cannot sample

original signal, and using it for
something else except spectrum analyzing

is hard.
Q6: OK. Thanks.

H: OK. Another question from the internet.
Signal angel: Yes. Have you compared the

sample rate of the ADC of the Lime DA chip
to the USRP ADCs, and if so, how does the

lower sample rate affect the performance?
AC: So, comparing low sample rate to

higher sample rate. We haven't done much
testing on the RF performance yet, because

we were so busy with all this stuff, so we
are yet to see in terms of low bit rates

versus sample rates versus high sample
rate. Well, high sample rate always gives

you better performance, but you also get
higher power consumption. So, I guess it's

the question of what's more more important
for you.

H: Okay. Over there.
Question 7: I've gathered there is no

mixer bypass, so you can't directly sample
the signal. Is there a way to use the same

antenna for send and receive, yet.
AC: Actually, there is... Input for ADC.

SK: But it's not a bypass, it's a
dedicated pin on LMS chip, and since we're

very space-constrained, we didn't route
them, so you can not actually bypass it.

AC: Okay, in our specific hardware, so in
general, so in the LMS chip there is a

special pin which allows you to drive your
signal directly to ADC without all the

mixers, filters, all this radio stuff,
just directly to ADC. So, yes,

theoretically that's possible.
SK: We even thought about this, but it

doesn't fit this design.
Q7: Okay. And can I share antennas,

because I have an existing laptop with
existing antennas, but I would use the

same antenna to send and receive.
AC: Yeah, so, I mean, that's... depends on

what exactly do you want to do. If you
want a TDG system, then yes, if you

want an FDG system, then you will have to
put a small duplexer in there, but yeah,

that's the idea. So you can plug this into
your laptop and use your existing

antennas. That's one of the ideas of how
to use xtrx.

Q7: Yeah, because there's all four
connectors.

AC: Yeah. One thing which I actually
forgot to mention is - I kind of mentioned

in the slides - is that any other SDRs
which are based on Ethernet or on the USB

can't work with a CSMA wireless systems,
and the most famous CSMA system is Wi-Fi.

So, it turns out that because of the
latency between your operating system and

your radio on USB, you just can't react
fast enough for Wi-Fi to work, because you

- probably you know that - in Wi-Fi you
carrier sense, and if you sense that the

spectrum is free, you start transmitting.
Does make a sense when you have huge

latency, because you all know that... you
know the spectrum was free back then, so,

with xtrx, you actually can work with CSMA
systems like Wi-Fi, so again it makes it

possible to have a fully software
implementation of Wi-Fi in your laptop. It

obviously won't work like as good as your
commercial Wi-Fi, because you will have to

do a lot of processing on your CPU, but
for some purposes like experimentation,

for example, for wireless labs and R&amp;D
labs, that's really valuable.

Q7: Thanks.
H: Okay. Over there.

Q8: Okay. what PCB design package did you
use?.

AC: Altium.
SK: Altium, yeah.

Q8: And I'd be interested in the PCIe
workshop. Would be really great if you do

this one.
AC: Say this again?

Q8: Would be really great if you do the
PCI Express workshop.

AC: Ah. PCI Express workshop. Okay. Thank
you.

H: Okay, I think we have one more question
from the microphones, and that's you.

Q9: Okay. Great talk. And again, I would
appreciate a PCI Express workshop, if it

ever happens. What are these
synchronization options between multiple

cards. Can you synchronize the ADC clock,
and can you synchronize the presumably

digitally created IF? SK: Yes, so... so,
unfortunately, just IF synchronization is

not possible, because Lime chip doesn't
expose a low frequency. But we can

synchronize digitally. So, we have special
one PPS signal synchronization. We have

lines for clock synchronization and other
stuff. We can do it in software. So the

Lime chip has phase correction register,
so when you measure... if there is a phase

difference, so you can compensate it on
different boards.

Q9: Tune to a station a long way away and
then rotate the phase until it aligns.

SK: Yeah.
Q9: Thank you.

AC: Little tricky, but possible. So,
that's one of our plans for future,

because we do want to see, like 128 by 128
MIMO at home.

H: Okay, we have another question from the
internet.

Signal angel: I actually have two
questions. The first one is: What is the

expected price after a prototype stage?
And the second one is: Can you tell us

more about this setup you had for
debugging the PCIe

issues?
AC: Could you repeat the second question?

SK: It's ????????????, I think.
SA: It's more about the setup you had for

debugging the PCIe issues.
SK: Second question, I think it's most

about our next workshop, because it's a
more complicated setup, so... mostly

remove everything about its now current
presentation.

AC: Yeah, but in general, and in terms of
hardware setup, that was our hardware

setup, so we bought this PCI Express to
Thunderbolt3, we bought the laptop which

supports Thunderbolt3, and that's how we
were debugging it. So, we don't need, like

a full-fledged PC, we don't have to
restart it all the time. So, in terms of

price, we don't have the fixed price yet.
So, all I can say right now is that we are

targeting no more than your bladeRF or
HackRF devices, and probably even cheaper.

For some versions.
H: Okay. We are out of time, so thank you

again Sergey and Alexander.
[Applause]

[Music]

subtitles created by c3subtitles.de
in the year 20??. Join, and help us!