[hpsdr] Hermes II

Tue Jan 23 06:12:13 PST 2018

I think that daily use of a SDR radio board does not mean you have to restrict
it for ONLY your own contesting activities and preventing other from
experimenting with openhpsdr as if it was a red pitaya thing, with better
performance (thats the goal of the project right?)

I would be very interested to get the opinion from the openhpsdr project leadership.

because, according to the openhpsdr website:

The HPSDR is an open source (GNU type) hardware and software project intended as
a "next generation" Software Defined Radio (SDR) for use by Radio Amateurs
("hams") and Short Wave Listeners (SWLs). It is being designed and developed by
a group of SDR enthusiasts with representation from interested experimenters
worldwide.

So yes, it's made for experimenters, not daily rag chewing...

I believe you were misleaded by apache labs commercial stuff "inspired from" the
openhpsdr project.

Sebastien

Le 23/01/2018 à 12:42, K4KV a écrit :
> ***** High Performance Software Defined Radio Discussion List *****
>
> Sebastien,
>
> I completely disagree.  You could not be more wrong.  However, there is
> nothing wrong with experimentation and play.
>
> I think many (most) of us use these transceivers every day for communicating. 
> This is my main transceiver,
> and I want it to have the latest and most practical technology.
>
> If I wanted to experiment, I would use the red pitaya or the lime board.
>
> 73
>
> Glen K4KV
>
>
>
> On 1/23/2018 06:06, Sebastien F4GRX wrote:
>> ***** High Performance Software Defined Radio Discussion List *****
>>
>> I agree with Marc
>>
>> SDR is not for feeding contest audio to your ears.
>>
>> it is possible to do that but it's not the goal. it would be an extremely poor
>> definition of SDR.
>>
>> SDR is generic radio DSP, and this one has high performance in its name.
>>
>> So why should the hardware limited to 192 kHz HD AUDIO like bandwidths, for
>> example?
>>
>> Some people want to be able to use a HIGH PEFORMANCE SDR for high performance
>> radio links, experimenting with unprecedented protocols, eg spread spectrum,
>> high data rate, etc.
>>
>> Some hackers are even using these kinds products for very diverse use like
>> security research.
>>
>> SDR is software, so the VFO button, mike, cq parrot... etc... should be
>> connected to a PC via USB or something else. You can use very cool material
>> designed for audio production to emulate your favorite Icom 7000 like rig.
>>
>> There is NO FUTURE in trying to make SDR boards as close to commercial
>> transceivers as possible. If you want that, buy rigs instead. SDR is for
>> experimentation. Look at the HackRF, LimeSDR, AirSpy, Ref Pitaya... and then
>> make that higher performance, and OPEN.
>>
>> Sebastien de F4GRX
>>
>>
>> Le 20/01/2018 à 17:55, Marc OLANIE a écrit :
>>> ***** High Performance Software Defined Radio Discussion List *****
>>>
>>> Hi
>>>
>>>> 1.  Quit focusing on how many receivers the units can do.  Two are nice,
>>>> but I cannot see anyone
>>> effectively using 7 or more(the majority of us).
>>>
>>> I'm using 14 of them daily. Ham radio is NOT only ragchewing and contesting.
>>> It's experimenting, and new digital modulation schemes -and/or real time
>>> propagation prediction tool- definitely need multi RX and probably multi-TX
>>> in a short term evolution. (I do not particularly appreciate JTxx and FT8
>>> traffic, but this could be an example amongst many others that need many
>>> simultaneous receivers on different bands)
>>>
>>>> 2.  Start moving towards VHF and UHF capabilities.  The chips are available
>>>> now.
>>> Agreed if exploiting niquist zone or parallelized ADC, but not mandatory. A
>>> good baseband rig is far better than any super-duper-multi-RX doing a lot of
>>> things with a lot of birds
>>>
>>> But indeed, a low phase noise, high dynamic, spur free baseband rig with a
>>> lot of easy to operate transverter switching capabilities would be
>>> appreciated. Kinda "super IF" for my 10 GHz station.
>>>
>>>> 3.  Too much concern about how powerful the FPGA is.  As I remember, the
>>>> mature code in the Hermes
>>> Don't agree. Hermes code and signal handling is frustrating. Dealing with
>>> "audio" segment when you have the ability do deal with 60 MHz of bw is an
>>> incredible limitation. (some people don’t only use their ears to "listen" to
>>> frequencies... and less and less people will do in the future... I
>>> definitely need to work at least with 2 MHz wide waveforms). Hermes code is
>>> a really nice piece of ham equipment, but it is still based on a more than
>>> 10 years old architecture. And this evolution -and the evolution of the
>>> frontend- needs a rather powerful datacrunching unit.
>>>
>>> FPGA is a bottleneck. A combination of fpga and GPU or using several gpu's
>>> has been mentioned several times.
>>>
>>>> 4.  Think about direct connection for an lcd screen, mouse, and keyboard.
>>> I really don't understand why more than some antennas inputs and a gigabit
>>> ethernet (or PCI, fddi, whatever high speed bus) would be helpful... please,
>>> resist doing the same mistake Japanese manufacturers tend to impose to the
>>> "market". I'm not a "market", I'm a radio ham, and my different SDRs are on
>>> my roof, connected via the network. I don't need to "see" my rig or "listen"
>>> to a speaker connected to it.
>>>
>>> I'm not trying to "troll" Glenn and I understand his point of view. I'm just
>>> trying to show that opinions could definitely diverge and it would be
>>> unappropriated to
>>> - force the development team to adopt a solution that fits personal point of
>>> view
>>> - try to imitate the "commercial trends" ruled by  the "big three" (buttons,
>>> lights, only contest/dx aware rigs)
>>> - definitely block all ham waiting for a real new generation of SDR that
>>> would nuke all the present limitations or the Hermes v1 familly
>>>
>>> Just my 2 cts
>>> Marc f6itu
>>>
>>>
>>> _______________________________________________
>>> HPSDR Discussion List
>>> To post msg: hpsdr at openhpsdr.org
>>> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
>>> HPSDR web page: http://openhpsdr.org
>>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>>
>> _______________________________________________
>> HPSDR Discussion List
>> To post msg: hpsdr at openhpsdr.org
>> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
>> HPSDR web page: http://openhpsdr.org
>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/