Hi,
I’m trying to adapt openbts to the inband firmware for which the source
are available. (it seems the sources for the std_inband.rbf that openbts
uses has been ‘lost’)
Two things I’m faced with
-
How can I know the ‘current’ TX timestamp ? I want to send a ping
command, but I don’t see a way to know what timestamp I should use.
-
The timestamp seems imprecise: I often get a timestamp difference
between two packets of 24191 or 24193 while I should in fact get 24192
(I’m at 192 decimation). With such a high decimator, I can fix it up
myself, but still, that looks weird.
Cheers,
Sylvain
On Thu, Aug 12, 2010 at 8:27 AM, Sylvain M. [email protected] wrote:
Hi,
I’m trying to adapt openbts to the inband firmware for which the source
are available. (it seems the sources for the std_inband.rbf that openbts
uses has been ‘lost’)
Two things I’m faced with
- How can I know the ‘current’ TX timestamp ? I want to send a ping
command, but I don’t see a way to know what timestamp I should use.
I think there is a “NOW” timestamp of all F’s.
- The timestamp seems imprecise: I often get a timestamp difference
between two packets of 24191 or 24193 while I should in fact get 24192
(I’m at 192 decimation). With such a high decimator, I can fix it up
myself, but still, that looks weird.
From what I remember, there were some issues with that count. I am
not sure if anyone fixed them.
Cheers,
Sylvain
Good luck.
Brian
Sylvain -
On Thu, 2010-08-12 at 14:27 +0200, Sylvain M. wrote:
- How can I know the ‘current’ TX timestamp ? I want to send a ping
command, but I don’t see a way to know what timestamp I should use.
It is in the header of every Rx packet. If you need to send a command
without knowing the current timestamp, use timestamp = 0, which will
always execute immediately. (There are some caveats which can usually
be ignored)
- The timestamp seems imprecise: I often get a timestamp difference
between two packets of 24191 or 24193 while I should in fact get 24192
(I’m at 192 decimation). With such a high decimator, I can fix it up
myself, but still, that looks weird.
Which inband code are you using exactly? My inband work (which was in
the ets developer branch) fixed exactly that problem. The root cause
was that time-stamping was done after sample buffering, so the stamps
would vary based on the buffer levels.
The new code is accurate and reflects the exact value of the 64MHz
counter for the first sample in the packet. There is an additional
offset between rx/tx times at analog due to various signal processing
stages before the time-stamping (which can vary depending on the FPGA
configuration). This value is easily compensated for on the host.
–Eric S.
Correction: As Brian stated, I think 0xffffffff is the correct “NOW”
timestamp.
Hi Eric,
- How can I know the ‘current’ TX timestamp ? I want to send a ping
command, but I don’t see a way to know what timestamp I should use.
It is in the header of every Rx packet. If you need to send a command
without knowing the current timestamp, use timestamp = 0, which will
always execute immediately. (There are some caveats which can usually
be ignored)
Mmm, in the code I’ve read, the tx timestamp counter was different than
the rx timestamp counter and with different reset signals.
- The timestamp seems imprecise: I often get a timestamp difference
between two packets of 24191 or 24193 while I should in fact get 24192
(I’m at 192 decimation). With such a high decimator, I can fix it up
myself, but still, that looks weird.
Which inband code are you using exactly?
I’m looking at git://git.ettus.com/ettus/fpga.git which AFAIK it the
most ‘official’ repo I could find.
My inband work (which was in
the ets developer branch) fixed exactly that problem. The root cause
was that time-stamping was done after sample buffering, so the stamps
would vary based on the buffer levels.
The new code is accurate and reflects the exact value of the 64MHz
counter for the first sample in the packet. There is an additional
offset between rx/tx times at analog due to various signal processing
stages before the time-stamping (which can vary depending on the FPGA
configuration). This value is easily compensated for on the host.
Nice.
In which git is that code ? And more importantly, why isn’t it in the
main repo 
As I’d like the inband function to become mainline in the future UHD
support, I think it’s important to make sure the code is pushed.
Cheers,
Sylvain
On Thu, Aug 12, 2010 at 09:51:31AM -0600, Eric S. wrote:
main repo 
It was in the old svn repo. It seems to have been migrated to git:
http://gnuradio.org/cgit/ets.git/tree/usrp/fpga/inband_lib?h=inband
I’m not sure why it didn’t merge into master. Probably because there is
not much use or interest in it.
Actually, I think it was because we weren’t sure it worked and/or that
there was no test code, and/or nobody said, “hey it really works!”
It would be great to get it integrated somehow, since I know that Eric
fixed many problems.
The main-line usrp source is now hosted
by Ettus, so we will have to work with them to make anything official.
On Thu, 2010-08-12 at 17:14 +0200, Sylvain M. wrote:
Mmm, in the code I’ve read, the tx timestamp counter was different than
the rx timestamp counter and with different reset signals.
This is all from memory…
There were two clocks, but the resets should have been tied together.
If the tx and rx clocks were not synchronized that would defeat the
whole point…
I do remember experimenting with a single counter. I do not remember if
I ended up using 1 or 2 though. I do recall that timing was harder to
meet with a single clock.
I’m looking at git://git.ettus.com/ettus/fpga.git which AFAIK it the
most ‘official’ repo I could find.
I think that one is broken.
In which git is that code ? And more importantly, why isn’t it in the
main repo
It was in the old svn repo. It seems to have been migrated to git:
http://gnuradio.org/cgit/ets.git/tree/usrp/fpga/inband_lib?h=inband
I’m not sure why it didn’t merge into master. Probably because there is
not much use or interest in it. The main-line usrp source is now hosted
by Ettus, so we will have to work with them to make anything official.
As I’d like the inband function to become mainline in the future UHD
support, I think it’s important to make sure the code is pushed.
There was some recent chat about that…
–Eric S.
Hi,
In which git is that code ? And more importantly, why isn’t it in the
main repo
It was in the old svn repo. It seems to have been migrated to git:
http://gnuradio.org/cgit/ets.git/tree/usrp/fpga/inband_lib?h=inband
Cool !
Unfortunately :
Error (10663): Verilog HDL Port Connection error at
rx_buffer_inband.v(273): output or inout port “num_packets” must be
connected to a structural net expression
And altough I’m fluent in VHDL, I have no idea about that verilog code
… I have no idea what that code is trying to do.
Cheers,
Sylvain
On Thu, 2010-08-12 at 23:25 +0200, Sylvain M. wrote:
Unfortunately :
Error (10663): Verilog HDL Port Connection error at
rx_buffer_inband.v(273): output or inout port “num_packets” must be
connected to a structural net expression
And altough I’m fluent in VHDL, I have no idea about that verilog code
… I have no idea what that code is trying to do.
It’s entirely possible for that version to have a syntax error. There
was a bad array declaration that an older Quartus would accept and a
newer one rejected. The newer one was more correct. :-/
I’m not going to have the time this week, but I’ll see if I can get the
most recent version (very few changes) available via git somewhere.
–ETS
most recent version (very few changes) available via git somewhere.
That’d be great.
Hi Sylvain,
Myself and another student were the main contributors of the inband
code, with much help from Eric, Matt, and Brian. We did a lot of
testing of the code, but the only main bug we had found was that the
timestamp on the RX side would occasionally jump. This was something
that I could never figure out (I’m not much of an FPGA coder), that
Eric S. finally chimed in and seemed to have fixed. We used the code
for various TDMA and CSMA MAC protocols and it seemed stable. The
main thing, IMO, keeping it out of the main codebase was that the
inband code relied on a bunch of GNU Radio primitives that were
eventually deprecated. The FPGA code itself though, is independent of
this.
It would be great to get Eric S’s code merged in to git somewhere
which fixes the timestamp jump and then move the code in to a
mainstream location.
Hi,
It’s entirely possible for that version to have a syntax error. There
was a bad array declaration that an older Quartus would accept and a
newer one rejected. The newer one was more correct. :-/
I managed to fix it (well, I think I did at least
But the generated code, altough meeting fmax constraint, has some
setup/hold violation.
Looking at the path, it seems there are latches (and not register) and
combinatorial signal being used as clocks … which is frightening for
FPGA code.
I’m not going to have the time this week, but I’ll see if I can get the
most recent version (very few changes) available via git somewhere.
That’d be great.
Sylvain
Quoting George N. ([email protected]):
[…]
It would be great to get Eric S’s code merged in to git somewhere
which fixes the timestamp jump and then move the code in to a
mainstream location.
What very interesting timing. (Ugh, pun not intended.)
Last night at about 11PM I was trying to figure out why the timestamps
in the gnuradio-3.3.0 usrp/fpga/rbf/rev4/inband_1rxhb_1tx.rbf were
always +/- 1 of where they are supposed to be: (normalized with the
current decimation)
126.007812
125.992188
126.007812
125.992188
126.007812
125.992188
126.007812
125.992188
126.007812
I decided to sleep on it and then search through the list to see if this
had been discussed.
Anyway, this is just a “me too!”