Up to six receivers SDR receiver compatible with HPSDR #3
Comments
|
According to the developers, the Hermes module (Protocol_1) can only support 4 receivers due to limited space within the FPGA. Further, 4 receivers at 384ksps consumes about 74 Mb/s on the interface. Also, Hermes (Protocol_1) is limited to 100 Mbit/s on the Ethernet interface. Steve AD0ES is working on an interface to the new (under development) Protocol_2 FPGA code that may support many more receivers. Hermes Protocol_2 can support 1 GE if modifications are made to some power components on the Hermes board. He left a message on the HPSDR reflector: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/2017-May/098041.html There are some other reflector reply posts on the same date with comments from the developers on Protocol_1 limitations. The current gr-hpsdr only supports Protocol_1, as the proposed new Protocol_2 is completely different. gr-hpsdr provides fairly complete support of HPSDR (including Alex filter selection, antenna relay control, amplifier PTT, etc.) Steve's planned code I think is more limited in feature support. Since I don't know your detailed requirements, you may want to discuss with Steve AD0ES (email via the above link). Then please let me know which direction you would like to go. I cannot start looking at code until July due to some other commitments. Tom, N5EG |
|
Hello,
Thank you for fast replying.
I'm a little confused.
We would like to use red pitaya with multiple project HPSDR which can run
up to six receivers with HPSDR / Metis communication protocol.
http://pavel-demin.github.io/red-pitaya-notes/sdr-receiver-hpsdr/
It seems that your current version of the hpsdr block allows you to
communicate with this project. So for me it's protocol 1.
If you look at the page, you will see that this devellopement is used with
six receivers.
In fact on the page you will find this documentation:
http://svn.tapr.org/repos_sdr_hpsdr/trunk/Documentation/USB_protocol_V1.58.doc
In this documentation it can be seen that up to 8 receivers can be used. But
due to some limitations of the redpitaya and lack of LUT we can only go up
to 6.
It is not a problem for us to wait, but if it is not possible we will have
to find another solution.
Tell me what you think of that. In any case for us, your block is certainly
the best solutions if we want to master the holders and the outcome.
Thank you anyway
2017-05-09 16:32 GMT+02:00 Tom McDermott, N5EG <notifications@github.com>:
… According to the developers, the Hermes module (Protocol_1) can only
support 4 receivers due to limited space within the FPGA. Further, 4
receivers at 384ksps consumes about 74 Mb/s on the interface. Also, Hermes
(Protocol_1) is limited to 100 Mbit/s on the Ethernet interface.
Steve AD0ES is working on an interface to the new (under development)
Protocol_2 FPGA code that may support many more receivers. Hermes
Protocol_2 can support 1 GE if modifications are made to some power
components on the Hermes board. He left a message on the HPSDR reflector:
http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
2017-May/098041.html
There are some other reflector reply posts on the same date with comments
from the developers on Protocol_1 limitations. The current gr-hpsdr only
supports Protocol_1, as the proposed new Protocol_2 is completely different.
gr-hpsdr provides fairly complete support of HPSDR (including Alex filter
selection, antenna relay control, amplifier PTT, etc.) Steve's planned code
I think is more limited in feature support.
Since I don't know your detailed requirements, you may want to discuss
with Steve AD0ES (email via the above link). Then please let me know which
direction you would like to go.
I cannot start looking at code until July due to some other commitments.
Tom, N5EG
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARgDWlgpvYY0pKL6JY3emCfoIqAbXjIVks5r4HkNgaJpZM4NUGu1>
.
|
|
OK, so you are interested in the Red Pitaya module. I do not have a Red Pitaya module, only the Hermes hardware to test with. To implement 6 receivers means that I could not test, just implement to the specification and hope that it works OK. My past experience has been that if something cannot be tested it probably won't work the first time. Some options: -- Tom, N5EG |
|
Hello,
There is no problem if you can add the specifications and I would be happy
to do the debugging.
Reading a code already done, putting it in place and correcting it is in
our competence.
If this solution is good for you, it is for me.
Thank you!
2017-05-10 5:37 GMT+02:00 Tom McDermott, N5EG <notifications@github.com>:
… OK, so you are interested in the Red Pitaya module. I do not have a Red
Pitaya module, only the Hermes hardware to test with.
To implement 6 receivers means that I could not test, just implement to
the specification and hope that it works OK. My past experience has been
that if something cannot be tested it probably won't work the first time.
Some options:
A. I could throw the software 'over the wall' and you test, and if
necessary fix. This is an open source source software project so the code
and the build environment are available, and changes (pull request) can be
fed back.
B. I find Red Pitaya to test with.
C. Perhaps there are some other ideas?
-- Tom, N5EG
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARgDWg_Fp8RNh4qVkKn9z0pmkcVyi4bRks5r4TDrgaJpZM4NUGu1>
.
|
|
I will look at this starting in July, at that time I will probably have some further questions. |
|
A new branch is available for testing, it is designed to support 1 to 7 receivers. It has been tested with 1 to 4 receivers on Hermes. It needs testing on Red Pitaya for up to 6 receivers. Please pull, git checkout the sevenrx branch, then build. Please let me know the success or failure of the testing so that the code can be fixed, or if successful the branch can be merged into the master branch. Ignore the README comments about Release Tags. That's just a placeholder for when testing is completed, the branch is merged and the tags are added. -- Tom, N5EG |
|
Hello Dear McDermott,
When you said July, I did not expect July 1.
This news filled me with joy.
I test this as soon as possible and keep you up to date in any case.
Thank you very much. I'll try to go fast.
Regards,
2017-07-01 12:08 GMT+02:00 Tom McDermott, N5EG <notifications@github.com>:
… A new branch is available for testing, it is designed to support 1 to 7
receivers. It has been tested with 1 to 4 receivers on Hermes. It needs
testing on Red Pitaya for up to 6 receivers. Please pull, git checkout the
sevenrx branch, then build. Please let me know the success or failure of
the testing so that the code can be fixed, or if successful the branch can
be merged into the master branch.
-- Tom, N5EG
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARgDWhS40vZsJQtWMHZ7j-GBR76PMxBCks5sJhqhgaJpZM4NUGu1>
.
|
|
Hello Dear McDermott,
We tested version 7 receivers tonight.
In the end it worked but during our tests we noticed things.
6 receivers in 192khz and 384khz are running (the tests are still to be
exploited over time)
When we switch to 96khz, when sending more than two receivers to alsa
loopback, a malloc error occurs.
When we switch to 48khz, we can only use one output of the block, since the
same malloc error occurs on the second output.
It may be that it comes from software redpitaya side.
In conclusion, 6 x 384khz have a promising start.
We will continue our tests in the coming days and weeks.
I would send you news and logs in detail if there are bugs.
Also, thanks to your work, we could replace our softrock by a redpiataya.
http://www.f4kji.fr
We decode live CW JT65 MSK144 and WSPR.
Please note that we are still in beta phase.
We hope to add very soon the 160m, 30m, 10m
Keep in mind that without you, we could not have achieved this.
Thank you so much for your work.
F4HTB
2017-07-01 12:08 GMT+02:00 Tom McDermott, N5EG <notifications@github.com>:
… A new branch is available for testing, it is designed to support 1 to 7
receivers. It has been tested with 1 to 4 receivers on Hermes. It needs
testing on Red Pitaya for up to 6 receivers. Please pull, git checkout the
sevenrx branch, then build. Please let me know the success or failure of
the testing so that the code can be fixed, or if successful the branch can
be merged into the master branch.
-- Tom, N5EG
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARgDWhS40vZsJQtWMHZ7j-GBR76PMxBCks5sJhqhgaJpZM4NUGu1>
.
|
|
Thank you for the initial report.
The gr-hpsdr driver does not do any heap allocation, deallocation, or
management - that is entirely handled by gnuradio. You may need to start
gnuradio-companion from the command line and set GDB to find out
which software is generating the error.
…-- Tom, N5EG
On Mon, Jul 3, 2017 at 1:56 PM, Olivier SCHMITT ***@***.***> wrote:
Hello Dear McDermott,
We tested version 7 receivers tonight.
In the end it worked but during our tests we noticed things.
6 receivers in 192khz and 384khz are running (the tests are still to be
exploited over time)
When we switch to 96khz, when sending more than two receivers to alsa
loopback, a malloc error occurs.
When we switch to 48khz, we can only use one output of the block, since the
same malloc error occurs on the second output.
It may be that it comes from software redpitaya side.
In conclusion, 6 x 384khz have a promising start.
We will continue our tests in the coming days and weeks.
I would send you news and logs in detail if there are bugs.
Also, thanks to your work, we could replace our softrock by a redpiataya.
http://www.f4kji.fr
We decode live CW JT65 MSK144 and WSPR.
Please note that we are still in beta phase.
We hope to add very soon the 160m, 30m, 10m
Keep in mind that without you, we could not have achieved this.
Thank you so much for your work.
F4HTB
2017-07-01 12:08 GMT+02:00 Tom McDermott, N5EG ***@***.***>:
> A new branch is available for testing, it is designed to support 1 to 7
> receivers. It has been tested with 1 to 4 receivers on Hermes. It needs
> testing on Red Pitaya for up to 6 receivers. Please pull, git checkout
the
> sevenrx branch, then build. Please let me know the success or failure of
> the testing so that the code can be fixed, or if successful the branch
can
> be merged into the master branch.
>
> -- Tom, N5EG
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#3#
issuecomment-312423346>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-
auth/ARgDWhS40vZsJQtWMHZ7j-GBR76PMxBCks5sJhqhgaJpZM4NUGu1>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHMenAn-snNiaWPL7D1pjNvcXM10QoTcks5sKVV_gaJpZM4NUGu1>
.
|
|
To use GDB to debug gnuradio-companion from command line: $ gdb --args python $(which gnuradio-companion) This may allow you to trace back which software is calling malloc improperly. |
|
Hello,
Thanks for this trick.
I will test without alsa as you sugest.
I send you some news as fast as possible.
2017-07-04 17:12 GMT+02:00 Tom McDermott, N5EG <notifications@github.com>:
… To use GDB to debug gnuradio-companion from command line:
$ gdb --args python $(which gnuradio-companion)
run
#wait for crash
bt //(gdb backtrace command)
This may allow you to trace back which software is calling malloc
improperly.
Just a note - on the gnuradio mailing list many folks have posted problems
over
the years using with alsa and gnuradio. Can you try the software without
using
alsa? i.e. just to a display or to a file?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARgDWu788fcW_83DGWh4GOr-Eo_UIrmLks5sKlZ7gaJpZM4NUGu1>
.
|
|
It turns out that C++ new actually calls malloc(). Revised code has been pushed to the sevenrx branch that wraps an exception handler around 'new' for the transmit and receive memory buffers. It will print a console error message if unable to create the memory buffers, then re-throw the exception which will kill the flowgraph immediately. This doesn't fix any issues, but at least it will make the source of the error more clear. The driver requires 64k bytes for the transmit buffers, and 128k bytes for the receive buffers. |
|
This has been merged to master. If there are problems, please open a new issue. |
|
Good news!
Thanks, we continue to test this but we expériency any problème with the
redpitaya.
After some time of work, the network chipset have an problem.
Sorry for the time that it take to test all...
But all seems to work great.
Can we quote you on our webpage with a word of thanks?
Le 11/07/2017 16:12, Tom McDermott, N5EG a écrit :
…
This has been merged to master. If there are problems, please open a
new issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARgDWpc7WIrJja1K9Z_hg-Qs7bJ43iV7ks5sM4LRgaJpZM4NUGu1>.
|
|
Hi Olivier - I'm glad that this works for you. Please feel free to quote
or reference
this work, and myself.
…-- Tom, N5EG
On Tue, Jul 11, 2017 at 12:14 PM, Olivier SCHMITT ***@***.***> wrote:
Good news!
Thanks, we continue to test this but we expériency any problème with the
redpitaya.
After some time of work, the network chipset have an problem.
Sorry for the time that it take to test all...
But all seems to work great.
Can we quote you on our webpage with a word of thanks?
Le 11/07/2017 16:12, Tom McDermott, N5EG a écrit :
>
> This has been merged to master. If there are problems, please open a
> new issue.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#3#
issuecomment-314456808>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-
auth/ARgDWpc7WIrJja1K9Z_hg-Qs7bJ43iV7ks5sM4LRgaJpZM4NUGu1>.
>
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHMenJE7xBNMt0GJ2bYMCIyU8A8SjUxyks5sM8mIgaJpZM4NUGu1>
.
|
|
Dear Tom,
I would just send you an email for say to you that we continue our
experiency on gr-hpsdr block.
This seems to work properly since we had our new redpitaya.
We do not know why, the first one had a defect on the chipset of the
network card and we could not use 1Gbits / s but only 100m and it was
already working with 4 receiver.
With 1Gbits / s the 6 seem to work but we keep checking.
I come back to you also because I would like to know if there exists a
block gnuradio to emulate a hermes receiver ?
In our project we would like to make a bridge between the redpitaya and
cwskimmer server with the hermes cwskimmer server driver.
So we should be able to emulate one.
If you ever know something, we are interested. CW skimmer server does
not support sound cards directly.
Tom, thanks you for all.
www.f4kji.fr
Le 11/07/2017 21:19, Tom McDermott, N5EG a écrit :
… Hi Olivier - I'm glad that this works for you. Please feel free to quote
or reference
this work, and myself.
-- Tom, N5EG
On Tue, Jul 11, 2017 at 12:14 PM, Olivier SCHMITT
***@***.***>
wrote:
> Good news!
>
> Thanks, we continue to test this but we expériency any problème with the
> redpitaya.
> After some time of work, the network chipset have an problem.
>
> Sorry for the time that it take to test all...
>
> But all seems to work great.
>
> Can we quote you on our webpage with a word of thanks?
>
>
>
> Le 11/07/2017 16:12, Tom McDermott, N5EG a écrit :
> >
> > This has been merged to master. If there are problems, please open a
> > new issue.
> >
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub
> > <#3#
> issuecomment-314456808>,
> > or mute the thread
> > <https://github.com/notifications/unsubscribe-
> auth/ARgDWpc7WIrJja1K9Z_hg-Qs7bJ43iV7ks5sM4LRgaJpZM4NUGu1>.
> >
>
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub
>
<#3 (comment)>,
> or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/AHMenJE7xBNMt0GJ2bYMCIyU8A8SjUxyks5sM8mIgaJpZM4NUGu1>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARgDWiih_MCFT20u6L-Q1v_YQu4RX-qLks5sM8rJgaJpZM4NUGu1>.
|
|
Hi Olivier,
I am not clear about your request. Is the purpose so that you can test
gnuradio flowgraph
without having any actual hardware ?
You may wish to look at this module, it emulates HPSDR:
https://github.com/ahopper/Patroclus
I think it runs on Windows but appears to run on a separate computer, so it
might
be OK for you?
Have you contacted the author of CWskimmer to see if he has implemented an
interface to
Red Pitaya?
…-- Tom, N5EG
On Wed, Sep 6, 2017 at 5:18 AM, Olivier SCHMITT <notifications@github.com>
wrote:
Dear Tom,
I would just send you an email for say to you that we continue our
experiency on gr-hpsdr block.
This seems to work properly since we had our new redpitaya.
We do not know why, the first one had a defect on the chipset of the
network card and we could not use 1Gbits / s but only 100m and it was
already working with 4 receiver.
With 1Gbits / s the 6 seem to work but we keep checking.
I come back to you also because I would like to know if there exists a
block gnuradio to emulate a hermes receiver ?
In our project we would like to make a bridge between the redpitaya and
cwskimmer server with the hermes cwskimmer server driver.
So we should be able to emulate one.
If you ever know something, we are interested. CW skimmer server does
not support sound cards directly.
Tom, thanks you for all.
www.f4kji.fr
Le 11/07/2017 21:19, Tom McDermott, N5EG a écrit :
> Hi Olivier - I'm glad that this works for you. Please feel free to quote
> or reference
> this work, and myself.
>
> -- Tom, N5EG
>
>
>
>
> On Tue, Jul 11, 2017 at 12:14 PM, Olivier SCHMITT
> ***@***.***>
> wrote:
>
> > Good news!
> >
> > Thanks, we continue to test this but we expériency any problème with
the
> > redpitaya.
> > After some time of work, the network chipset have an problem.
> >
> > Sorry for the time that it take to test all...
> >
> > But all seems to work great.
> >
> > Can we quote you on our webpage with a word of thanks?
> >
> >
> >
> > Le 11/07/2017 16:12, Tom McDermott, N5EG a écrit :
> > >
> > > This has been merged to master. If there are problems, please open a
> > > new issue.
> > >
> > > —
> > > You are receiving this because you authored the thread.
> > > Reply to this email directly, view it on GitHub
> > > <#3#
> > issuecomment-314456808>,
> > > or mute the thread
> > > <https://github.com/notifications/unsubscribe-
> > auth/ARgDWpc7WIrJja1K9Z_hg-Qs7bJ43iV7ks5sM4LRgaJpZM4NUGu1>.
> > >
> >
> > —
> > You are receiving this because you modified the open/close state.
> > Reply to this email directly, view it on GitHub
> >
> <#3#
issuecomment-314543753>,
> > or mute the thread
> >
> <https://github.com/notifications/unsubscribe-auth/
AHMenJE7xBNMt0GJ2bYMCIyU8A8SjUxyks5sM8mIgaJpZM4NUGu1>
> > .
> >
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#3#
issuecomment-314545037>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-
auth/ARgDWiih_MCFT20u6L-Q1v_YQu4RX-qLks5sM8rJgaJpZM4NUGu1>.
>
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHMenFtJMzR5rSDOgTmGL3Bktmurz1Orks5sfo2LgaJpZM4NUGu1>
.
|
|
Hi Tom,
I have already contact Alex.
It proposes to send me the information to develop a DLL allowing to use
sound cards under the server version of cw skimmer.
I think it was feasible.
Use redpitaya is possible directly mais so juste only for cwskimmer. But
we use redpitaya also for websdr, wsjtx to.
Look the diagram joined.
The project you sent me seems very interesting and probably transposable
in a gnu radio brick.
I work for the University of Strasbourg, I will see if students can work
on the subject. We will see what that can give.
Today we are looking to use less CPU for decoding the CW.
We use CWSKIMER but it consumes too many resources (after one hour, when
CWskimmer stabilizes, 30% on 8 heart hyperthread).
With ca and the 6 receivers managed by gnuradio, 10 sessions of WSJTX,
our CPU runs at 3.8ghz 89% which leaves no margin. As soon as we have a
post processing script like generating curves or just sending raw cw to
websdr clients, there are cuts in the alsaloop.
So we must optimize all this and the first solution seen is to lower the
consumption of CWSKIMMER using the server version. We have already seen
several people say it is quite effective.
The problem is that CWSKIMMER server use drivers (dll) and directly
retrieves frames according to the different receiver (hermes metis usrp,
quicksilver, redpitaya pavel project ...)
The last solution I tried and that works (but it's not very clean) is to
recompile the ARM side process to run a second process.
But we have recompile alsaloop to use 384khz and cwskimmer only takes
192khz ....
I will keep you informed as soon as I have advanced.
Thank you again for your answers and help.
Olivier, F4HTB
Le 06/09/2017 17:02, Tom McDermott, N5EG a écrit :
… Hi Olivier,
I am not clear about your request. Is the purpose so that you can test
gnuradio flowgraph
without having any actual hardware ?
You may wish to look at this module, it emulates HPSDR:
https://github.com/ahopper/Patroclus
I think it runs on Windows but appears to run on a separate computer,
so it
might
be OK for you?
Have you contacted the author of CWskimmer to see if he has implemented an
interface to
Red Pitaya?
-- Tom, N5EG
On Wed, Sep 6, 2017 at 5:18 AM, Olivier SCHMITT ***@***.***>
wrote:
> Dear Tom,
>
> I would just send you an email for say to you that we continue our
> experiency on gr-hpsdr block.
> This seems to work properly since we had our new redpitaya.
> We do not know why, the first one had a defect on the chipset of the
> network card and we could not use 1Gbits / s but only 100m and it was
> already working with 4 receiver.
> With 1Gbits / s the 6 seem to work but we keep checking.
>
> I come back to you also because I would like to know if there exists a
> block gnuradio to emulate a hermes receiver ?
>
> In our project we would like to make a bridge between the redpitaya and
> cwskimmer server with the hermes cwskimmer server driver.
> So we should be able to emulate one.
>
> If you ever know something, we are interested. CW skimmer server does
> not support sound cards directly.
>
> Tom, thanks you for all.
>
> www.f4kji.fr
>
> Le 11/07/2017 21:19, Tom McDermott, N5EG a écrit :
> > Hi Olivier - I'm glad that this works for you. Please feel free to
quote
> > or reference
> > this work, and myself.
> >
> > -- Tom, N5EG
> >
> >
> >
> >
> > On Tue, Jul 11, 2017 at 12:14 PM, Olivier SCHMITT
> > ***@***.***>
> > wrote:
> >
> > > Good news!
> > >
> > > Thanks, we continue to test this but we expériency any problème with
> the
> > > redpitaya.
> > > After some time of work, the network chipset have an problem.
> > >
> > > Sorry for the time that it take to test all...
> > >
> > > But all seems to work great.
> > >
> > > Can we quote you on our webpage with a word of thanks?
> > >
> > >
> > >
> > > Le 11/07/2017 16:12, Tom McDermott, N5EG a écrit :
> > > >
> > > > This has been merged to master. If there are problems, please
open a
> > > > new issue.
> > > >
> > > > —
> > > > You are receiving this because you authored the thread.
> > > > Reply to this email directly, view it on GitHub
> > > > <#3#
> > > issuecomment-314456808>,
> > > > or mute the thread
> > > > <https://github.com/notifications/unsubscribe-
> > > auth/ARgDWpc7WIrJja1K9Z_hg-Qs7bJ43iV7ks5sM4LRgaJpZM4NUGu1>.
> > > >
> > >
> > > —
> > > You are receiving this because you modified the open/close state.
> > > Reply to this email directly, view it on GitHub
> > >
> > <#3#
> issuecomment-314543753>,
> > > or mute the thread
> > >
> > <https://github.com/notifications/unsubscribe-auth/
> AHMenJE7xBNMt0GJ2bYMCIyU8A8SjUxyks5sM8mIgaJpZM4NUGu1>
> > > .
> > >
> >
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub
> > <#3#
> issuecomment-314545037>,
> > or mute the thread
> > <https://github.com/notifications/unsubscribe-
> auth/ARgDWiih_MCFT20u6L-Q1v_YQu4RX-qLks5sM8rJgaJpZM4NUGu1>.
> >
>
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub
>
<#3 (comment)>,
> or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/AHMenFtJMzR5rSDOgTmGL3Bktmurz1Orks5sfo2LgaJpZM4NUGu1>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARgDWhok-2bKcvBQso90kkHsU7NP-Naqks5sfrP2gaJpZM4NUGu1>.
|
|
Hello Tom,
I just wanted to give you some news.
The 6-band gnuradio block works perfectly.
Concerning our CPU problems, we have found how to do it.
We will make a cluster with three computers:
- One for the interface between the redpitaya and the websdr with
between 4 and 6 network card.
- One or two with cwskimmer.
- One with wsjtx.
The streams between the main computer and the two beacon decoder is
audio sent in udp with gnuradio.
We did some tests tonight, it would look very promising!
This means that with a second redpiataya we will cover most HF bands and
decode msk144, jt65, wspr, FT8 and CW!
I'm really enthusiastic!
I give you news as soon as possible.
I say thank you again because your block is the main hinge of the whole
project!
Le 06/09/2017 17:02, Tom McDermott, N5EG a écrit :
… Hi Olivier,
I am not clear about your request. Is the purpose so that you can test
gnuradio flowgraph
without having any actual hardware ?
You may wish to look at this module, it emulates HPSDR:
https://github.com/ahopper/Patroclus
I think it runs on Windows but appears to run on a separate computer,
so it
might
be OK for you?
Have you contacted the author of CWskimmer to see if he has implemented an
interface to
Red Pitaya?
-- Tom, N5EG
On Wed, Sep 6, 2017 at 5:18 AM, Olivier SCHMITT ***@***.***>
wrote:
> Dear Tom,
>
> I would just send you an email for say to you that we continue our
> experiency on gr-hpsdr block.
> This seems to work properly since we had our new redpitaya.
> We do not know why, the first one had a defect on the chipset of the
> network card and we could not use 1Gbits / s but only 100m and it was
> already working with 4 receiver.
> With 1Gbits / s the 6 seem to work but we keep checking.
>
> I come back to you also because I would like to know if there exists a
> block gnuradio to emulate a hermes receiver ?
>
> In our project we would like to make a bridge between the redpitaya and
> cwskimmer server with the hermes cwskimmer server driver.
> So we should be able to emulate one.
>
> If you ever know something, we are interested. CW skimmer server does
> not support sound cards directly.
>
> Tom, thanks you for all.
>
> www.f4kji.fr
>
> Le 11/07/2017 21:19, Tom McDermott, N5EG a écrit :
> > Hi Olivier - I'm glad that this works for you. Please feel free to
quote
> > or reference
> > this work, and myself.
> >
> > -- Tom, N5EG
> >
> >
> >
> >
> > On Tue, Jul 11, 2017 at 12:14 PM, Olivier SCHMITT
> > ***@***.***>
> > wrote:
> >
> > > Good news!
> > >
> > > Thanks, we continue to test this but we expériency any problème with
> the
> > > redpitaya.
> > > After some time of work, the network chipset have an problem.
> > >
> > > Sorry for the time that it take to test all...
> > >
> > > But all seems to work great.
> > >
> > > Can we quote you on our webpage with a word of thanks?
> > >
> > >
> > >
> > > Le 11/07/2017 16:12, Tom McDermott, N5EG a écrit :
> > > >
> > > > This has been merged to master. If there are problems, please
open a
> > > > new issue.
> > > >
> > > > —
> > > > You are receiving this because you authored the thread.
> > > > Reply to this email directly, view it on GitHub
> > > > <#3#
> > > issuecomment-314456808>,
> > > > or mute the thread
> > > > <https://github.com/notifications/unsubscribe-
> > > auth/ARgDWpc7WIrJja1K9Z_hg-Qs7bJ43iV7ks5sM4LRgaJpZM4NUGu1>.
> > > >
> > >
> > > —
> > > You are receiving this because you modified the open/close state.
> > > Reply to this email directly, view it on GitHub
> > >
> > <#3#
> issuecomment-314543753>,
> > > or mute the thread
> > >
> > <https://github.com/notifications/unsubscribe-auth/
> AHMenJE7xBNMt0GJ2bYMCIyU8A8SjUxyks5sM8mIgaJpZM4NUGu1>
> > > .
> > >
> >
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub
> > <#3#
> issuecomment-314545037>,
> > or mute the thread
> > <https://github.com/notifications/unsubscribe-
> auth/ARgDWiih_MCFT20u6L-Q1v_YQu4RX-qLks5sM8rJgaJpZM4NUGu1>.
> >
>
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub
>
<#3 (comment)>,
> or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/AHMenFtJMzR5rSDOgTmGL3Bktmurz1Orks5sfo2LgaJpZM4NUGu1>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARgDWhok-2bKcvBQso90kkHsU7NP-Naqks5sfrP2gaJpZM4NUGu1>.
|
|
Hello Dear Tom,
I hope everything goes well for you.
The blocks work perfectly.
I'm coming back with a new request.
Pavel has updated its software for 8 receivers.
In the gr-hpsdr block we can already implement the 8 frequencies (from 0
to 7).
On the other hand in "Nym Rcvrs" we can put only 7 at the maximum and
not 8 which gives maximum 7 outputs. Can you correct on 8?
I think it must be forgotten.
Thanks in advance. The block you have developed is the backbone of our
project.
Le 11/07/2017 21:19, Tom McDermott, N5EG a écrit :
… Hi Olivier - I'm glad that this works for you. Please feel free to quote
or reference
this work, and myself.
-- Tom, N5EG
On Tue, Jul 11, 2017 at 12:14 PM, Olivier SCHMITT
***@***.***>
wrote:
> Good news!
>
> Thanks, we continue to test this but we expériency any problème with the
> redpitaya.
> After some time of work, the network chipset have an problem.
>
> Sorry for the time that it take to test all...
>
> But all seems to work great.
>
> Can we quote you on our webpage with a word of thanks?
>
>
>
> Le 11/07/2017 16:12, Tom McDermott, N5EG a écrit :
> >
> > This has been merged to master. If there are problems, please open a
> > new issue.
> >
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub
> > <#3#
> issuecomment-314456808>,
> > or mute the thread
> > <https://github.com/notifications/unsubscribe-
> auth/ARgDWpc7WIrJja1K9Z_hg-Qs7bJ43iV7ks5sM4LRgaJpZM4NUGu1>.
> >
>
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub
>
<#3 (comment)>,
> or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/AHMenJE7xBNMt0GJ2bYMCIyU8A8SjUxyks5sM8mIgaJpZM4NUGu1>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARgDWiih_MCFT20u6L-Q1v_YQu4RX-qLks5sM8rJgaJpZM4NUGu1>.
|
|
Hi Olivier, The HPSDR protocol only defines registers for 7 receivers. Tom, N5EG |
|
Hello Dear Tom,
First of all, thank you for this very quick answer.
After looking for a few hours on the internet, I contacted MR PAVEL
DEMIN directly who made the image of the redpitaya.
You will find this answer below.
According to him the logic remains the same.
So if the heart tells you and you have a little time, I'm interested.
PS: It will still be necessary that you give me your address on the
occasion so that I can send you a good bottle of Alsace wine :)
Thanks in advance.
F4HTB Olivier.
…-------- Message original --------
Sujet: Re: SDR receiver compatible with HPSDR and gnuradio gr-hpsdr
N5EG's Block
Date : Wed, 7 Mar 2018 12:21:19 +0000
De : Pavel Demin <pavel-demin@outlook.com>
Pour : Olivier SCHMITT <sc.olivier@gmail.com>
Hello Olivier,
All the links to the HPSDR documentation and to the source code of the
SDR receiver compatible with HPSDR can be found in my notes about this
project:
http://pavel-demin.github.io/red-pitaya-notes/sdr-receiver-hpsdr
As far as I know, the protocol is exactly the same for any number of
receivers from 1 to 8. It's described on page 4 of the HPSDR protocol
description:
http://svn.tapr.org/repos_sdr_hpsdr/trunk/Documentation/USB_protocol_V1.58.doc
My implementation of this protocol can be found on lines 260-392 in
sdr-receiver-hpsdr.c:
https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/sdr_receiver_hpsdr/server/sdr-receiver-hpsdr.c#L260-L392
Best regards,
Pavel
Olivier SCHMITT wrote:
Hello Mr. PAVEL DEMIN,
Dear OM, Allow me to contact you about "SDR receiver compatible with
HPSDR" an issue that I can not find the solution.
Indeed, I interact with MR Tom McDermott N5EG about the block gnuradio
gr-hpsdr that we use in our project F4KJI. (www.f4kji.fr)
We would like to fully use your last redpitaya implementation with 8
receivers with Tom's block. (https://github.com/Tom-McDermott/gr-hpsdr/)
Unfortunately Tom seems to have the necessary information on the
protocol up to 7 receivers, following the logic:
(https://github.com/Tom-McDermott/gr-hpsdr/blob/master/lib/HermesProxy.cc)
// Seven receivers - 11 Tx queue events per set of 63, 126, 252, 504
received frames
std::vector<int> L7_48 = { 6, 12, 17, 23, 29, 34, 40, 45, 51, 57, 62 };
// 11 frames per 63
std::vector<int> L7_96 = { 12, 24, 34, 46, 58, 68, 80, 90, 102, 114,
124 }; // 11 frames per 126
std::vector<int> L7_192 = { 24, 48, 68, 92, 116, 136, 160, 180, 204,
228, 248 }; // 11 frames per 252
std::vector<int> L7_384 = { 48, 96, 136, 184, 232, 272, 320, 360, 408,
456, 496 }; // 11 frames per 504
Can you tell us about the protocol for the 8 receivers?
Maybe you have documentation?
Thanks in advance. 73 F4HTB Olivier
|
|
Hi Olivier. The OpenHPSDR specification discusses how to buffer align 8 receivers, but the actual control register specification does not include any definition for the registers for the 8th receiver. In looking through Pavel's code (line 80 of the file referenced), it appears he uses the next logical register address after receiver 7 to program receiver number 8. However that register address is already used by OpenHPSDR for other functionality. The usage between the two applications is thus incompatible. IF I am reading Pavel's code correctly, use of the registers Pavel has defined for Red Pitaya would break the functionality of the Hermes / Alex modules. It is not possible to add an 8th receiver while maintaining compatibility between the Hermes and Red Pitaya. -- Tom, N5EG |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello dear N5EG sysop McDermott,
I hope this time in the right place to ask for a feature request.
We are working with gnuradio and today several receivers on the protocol hermes / metis can with up to 6 receivers on 384khz.
So I would like to ask you if it would be possible to adapt your librairy to use these 6 receivers?
Obviously we are consicent of the implication that this requires and we thank you in advance.
We will not fail to quote you in our publications because it is the only way for us to prove our gratitude to you.
In the meantime, please accept my sincere thanks.
73 F4HTB
The text was updated successfully, but these errors were encountered: