VNA Reflection Mode with Hermes-Lite

[James Ahlstrom]

Hello Group,

Quisk ships with a VNA program quisk_vna.py for use with the HiQSDR hardware.  I have been working on porting this so that it works with the Hermes-Lite too, and have hit some problems.  I am looking for some input from anyone that knows how VNA mode in the firmware works, or that has used Hermes-Lite in Reflection mode with any software like HamVNA.

In VNA mode, HL transmits a continuous sine wave, and I thought it would be nice to turn this off when HL was not scanning (Steve mentioned this).  After some misadventures, I found that if VNA mode is turned on and off, or if HL is power cycled, VNA mode comes back with a different phase between Tx and Rx.  That means that the only option is to start VNA mode, perform another calibration, and never turn it off.  This is contrary to the Hermes documentation, that says the calibration data can be saved.  So either the docs are wrong, HL has an obsolete VNA implementation, or I am mistaken.  If you use VNA Transmission mode, the phase does not matter, but it is essential for Reflection mode.

In VNA mode, the scanning is performed by the PC.  That is, the PC sets a new frequency, collects data, sets a new frequency, collects data, etc.  This creates the problem of figuring out what data coming from the HL corresponds to what frequency set by the PC.  The least significant bit of the microphone is supposed to be a frequency change indicator, but AFAIK this doesn't work.

The ADC overload indication is erratic in VNA mode.  So far, I discovered that if I start Quisk, exit, and start quisk_vna, the indicator works.  If I power cycle and start quisk_vna, no overload is ever indicated.

I am not expecting Steve or anyone else to "fix" this.  I just need some indication if I am crazy, or if someone out there can give me a clue.  Does anyone know if VNA mode in the new Hermes Ethernet firmware works the same way?

Even if all this can be fixed, it would be better to perform scanning in the FPGA, not in the PC.  That is the way the HiQSDR works, and the result is a real time display that changes continuously as you (for example) adjust your antenna tuner.  The comparison in VNA mode between HL and HiQSDR is stark.  FPGA changes are minimal.  You send the FPGA the start frequency, number of points, and the frequency to add for each point.  Then VNA mode uses a single Cordic (instead of Rx and Tx Cordics), changes the frequency for each point, and decodes the data.  Since the data is at DC, "decode" just means summing the samples.  Then the whole block of data is returned at once.

Jim

N2ADR

[Phil Harman]

Hi Jim,

I can confirm that the VNA function works correctly in v2.9 of the Hermes code. It looks like the mic bit is missing on later versions, I'm not sure why so need to check the source code. Both Alex's, VE3NEA, and my VNA PC code uses this bit to indicated that a change in frequency has been received by Hermes so the next (sweep) frequency can be sent. 

The phase relationship between Rx and Tx is retained (much to pleasure and surprise), in which case reloading calibration constants is all that is required when starting a new session.

VNA mode has not yet been implemented in the new protocol Hermes code but is on the very long list of things to do. 

Hope that is of assistance. 

73 Phil...VK6PH 

[James Ahlstrom]

Hello Phil,

Here is some more data.  The Hermes-Lite source code clearly indicates that the Tx frequency is set equal to the Rx frequency in VNA mode.  But if I scan by changing the Rx frequency, there is no change in frequency.  I must scan by changing the Tx frequency.  But turning VNA mode "On" does produce output, so VNA mode is being detected.  Maybe my FPGA program binary is out of date.  But I should mention that HamVNA does not work either.  My Metis Discovery Reply indicates a code version of 31 and board ID 6.

I am not very good at reading Verilog, but I am happy to take a look at this and see what I can find out.  I assume the code from  github.com/softerhardware/Hermes-Lite/rtl  is based on code in  svn.tapr.org/repos_sdr_hpsdr/trunk/Hermes/  but the code is in *.rbf files.  I guess these are Microsoft rollback files, but how do I open them and get the source?

Please put VNA for the new Ethernet protocol near the bottom of your list, as I would like to try moving the scan to the FPGA if I can manage it.

Jim

N2ADR

[Steve Haynal]

Hi Jim,

The last I tried, VNA was working in the SDK/CV branch. If I remember correctly, you have a SDK. Do the existing VNA programs work for you with the SDK? Unfortunately, you may have to change a couple of jumpers to use a CVA9 HL again with the SDK. As you say, something may be different with the CVA9 branch. I don't recall using the VNA with the CVA9.

My recollection is that VNA mode synchronizes the TX and RX cordic. The data out from the radio is now always the phase difference between TX and RX. The phase relation does not change when VNA mode is reenabled and should not need to be recalibrated. When first learning the openhpsdr VNA mode, I found looking at Phil's software on the svn.tapr.org server helpful:

http://svn.tapr.org/listing.php?repname=OpenHPSDR+Main&path=%2Ftrunk%2FHermes%2FVNA%2F&#ac856515cbd3f53db1ead42f15e044068

Internal fast scan on the FPGA sounds interesting.

The .rbf format is "raw binary format" and is one of the binary bitfile formats used by Altera. I think the original RTL is somewhere on the tapr svn, or is sometimes distributed as a .qar, Quartus Archive, file.

 

73,

Steve

KF7O

[James Ahlstrom]

Hi Steve,

I am testing with a CVA9, not SDK.  I tested with HamVNA, and it does not work.  But please stand by, as I may have done something stupid like using the wrong FPGA binary.  I plan to recompile from the source on your github site and retest.  The comment states that it is based on Phil's version 3.1.

I don't see anything that synchronizes the RX and TX cordics in the source, only a feature to make the frequencies the same.  But I am still studying the code.  Thanks for the svn.tapr.org reference as it is just what I need.  Phil contacted me and offered to send code too.

My thinking is that I fix VNA mode if it needs fixing, and then write documentation for it.  The result must work with HamVNA etc.  I can add fast scan to the "old" Hermes protocol, but I don't know if Phil will be interested enough to backport it.  Quisk_vna may be the only software to use it.  But I think it would be a great addition.  At some point I will look at porting the "new Ethernet" Hermes protocol, and will pester Phil to change the new VNA protocol to fast scan.

While we are on the subject of RTL, is there a reason to offer both Full Duplex and Half Duplex mode in the RTL?  It seems there should only be FD.  I was waiting to get a HL V2 board so I could work with the final RTL, but maybe CVA9 is close enough to make progress.

Jim

N2ADR

[Steve Haynal]

Hi Phil,

I'm fairly certain that VNA mode still works with the SDK or CV8 firmware. A good way to test this is to try HamVNA or Phil's software with your SDK. Yes, FD-only is my plan for HL2.0. There are substantial changes in the firmware since forking from 3.1. For example, the ADC/DAC interface is entirely different.

73,

Steve

KF7O

[Steve Haynal]

I meant to say Hi Jim. :)

[Alan Hopper]

Jim,

the pre 1.22 hermes lites can't do full duplex hence the option. Just a heads up on the full duplex cva9 firmware, I have had an on going love hate relationship with it, I believe the timing is right on the edge and small changes create rx noise floor issues. The current version on git seems to work fine but takes ages to build. I think I identified the problem with timing on one adc line but my lack of fpga skill and time have not allowed me to fix it.

I'm intrigued with your vna option and Steve's idea of semi continuous vna style antenna analysis in normal use, I think there are opportunities to better integrate this stuff into software.

73 Alan M0NNB

[Steve Haynal]

Hi Alan and Jim,

The CVA9 firmware has been neglected. I really haven't worked on it much lately and have focused on the Hermes-Lite 2.0 instead. I'm actually looking forward to focusing more on RTL once the Hermes-Lite 2.0 shows some signs of life. Any help with the CVA9 firmware is appreciated.

The fast scan VNA mode is desirable but I'm not too enthusiastic about putting that functionality on the FPGA even if it is minimal. I really want to move as much functionality as possible from the FPGA to software, and only keep functionality on the FPGA that is crucial for performance, latency and price. This keeps the door open to use lower cost FPGAs. When functionality is in software, it is more accessible to a larger group of contributors. In the past, I've mentioned how I want to move the final FIR filterering to software and use the gigabit bandwidth. This follows the same philosophy and is still where I'd like to go. One could say that the direct Fourier conversion (DFC) effort is the final fruition of this philosophy, although if cost is a prime priority I don't think we are quite there yet.

Can a fast scan VNA mode be implemented mainly on the software side? If you consider just a 100 Mb/s ethernet link and a 30 fps update rate for real time visualization, this is ~400 kBytes of communication possible within a single display frame. Even for the highest resolution displays with 3840 pixels, you have about 100 bytes of communication per pixel for a horizontal plot. Only 3 bytes per pixel are needed if you want color. You could tolerate 97% inefficiencies. We will have gigabit ethernet. 30 fps is also faster than we absolutely need. 3840 pixels is pretty high resolution. Maybe we can have a real time VNA feel with most functionality in software.

73,

Steve

KF7O

[Alan Hopper]

Jim, Steve,

one issue I have with both the old and new protocol is the lack of metadata in the data packets, it is a guessing game as to what exact frequency, gain and sample rate a given packet was collected at when things are changing.  If we could add this data and only apply changes sync'd with packets would that help with vna? It would be useful for my sw rf agc as I currently don't know when to start applying the new gain to incoming packets.

73 Alan M0NNB

[James Ahlstrom]

Hello Alan and Steve,

There are two problems with implementing the VNA in the PC instead of the FPGA.  Alan put his finger on the first.  When the PC changes the frequency for each point, it needs to know which samples go with which frequency.  Current VNA mode "solves" this by marking a frequency change with a single bit, but it is hard to have confidence that this never goes out of phase.  Since commands are sent with a sequence number, we could return the last sequence number with samples; but the sequence number is 32 bits, and it is not efficient to include this with each sample.  We could mark the Ethernet block with the sequence number for little added overhead, but that is not very fine grained.

The second problem is not bandwidth, but latency.  Consider updating a 1000 point graph only once a second.  You have 1 millisecond for each point.  The timing is (1) change the frequency, (2) wait for the new frequency to make its way through the cordic steps and any filters, wait for the external circuit (maybe an antenna) to stabilize, (3) add up some suitable number of points for the average response, (4) repeat.  A PC is not a real time device, and neither is the network.  You could do the waiting in the PC, but there would be the danger/inconvenience of changing the frequency too fast (not enough wait time) or too slowly (longer scan time).

We could provide a solution to both problems, but at best it is awkward.  Please see the separate post on PC/FPGA software division.

Jim

N2ADR

[James Ahlstrom]

Hello Steve,

I don't think it is correct to say the CVA9 firmware has been neglected.  The CVA9 firmware works fine.  Now that I am looking more at the firmware, I see that you implemented code for four versions of BeMicro, two AD9866 interfaces (full word and nibble), and several clocks.  My hat is off to you.  It will be a relief to get back to a single RTL for HL V2, but for now, great work Steve!

I see your point about wanting to do most work in the PC, but I would argue for a careful division.  Quisk always offered sample rates up to 960ksps, but my old Intel Atom desktop PC would choke on the higher rates.  HL will be popular with the single board computer crowd, and I question whether an ARM processor can do much with a Gig data stream.  For example, I would not move the final FIR (after the Rx CIC filters) to the PC because the operation is standard and unlikely to change, and it results in 8 times greater bandwidth usage and a burden on the PC that is easily avoided.

I will definitely pursue a PC-only VNA.  For now, that is what we have and I want to understand it and make it work.  But I doubt it can be great within the current protocol.  We could extend the protocol but I think we should try to maintain compatibility with Phil's "old" protocol, and try to make it easy for him to backport any changes he wants.

Jim

N2ADR

[Alan Hopper]

Jim,

yep my hat is definitely off to Steve for his support for so many boards and am very grateful for all the work he put into the cva9 which I believe was a bit of a distraction from the long term goals of the project.  I am a supporter of the idea to move the fir to the pc if it means we can fit more receivers in. Phil's receiver for the new protocol code only does 2:1 decimation in the fir so the network issue is not so bad, there is an issue in that the new cics use more gates than the current ones but I suspect this can be optimised.

If I understand your previous post, you suggest we could return the tx packet seq no that has just been acted on in the rx packet, I can see this being useful. 

73 Alan M0NNB

[Steve Haynal]

Hi Jim,

I agree with Alan's point that we need a better way to know which frequency a returning packet was generated with.

I also agree that latency will be the bottleneck in trying to do VNA closer to realtime and mainly in software. However, I'm not convinced latency is a killer. I just did a ping flood to my CVA9 board over my home network. On average packet round trip times are 0.084 ms. Although the ping flood lasted for 20 seconds, this did not interrupt my family's streaming of audio over the same network. These are ICMP packets, but what we have shouldn't be 10 times worse, and we may be able to improve RTT of what we have.

shiva shaynal # ping -f -c 200000 192.168.33.249

PING 192.168.33.249 (192.168.33.249) 56(84) bytes of data.

 

--- 192.168.33.249 ping statistics ---

200000 packets transmitted, 200000 received, 0% packet loss, time 22111ms

rtt min/avg/max/mdev = 0.056/0.084/0.285/0.008 ms, ipg/ewma 0.110/0.084 ms

I couldn't find your post on PC/FPGA software division.

73,

Steve

KF7O

[Steve Haynal]

Hi Jim,

The CVA9 firmware does work, but in terms of timing closure for many >4 receivers (it seems brittle when attempting anything new in the RTL) and testing that all functionality (VNA, etc.) is covered, I still think it has been neglected.

Regarding SBCs, many are now quite powerful, with multicore CPUs and GPUs that support OpenCL. They may be able to do more than your old Atom desktop. Still, I don't want to reduce the size of the FPGA such that it can not fit a final FIR filter. I would want people to be able to use a firmware that does do most of the processing on the FPGA even if it is only for 1 receiver and 1 transmitter with a SBC. But I want and am interested in the possibility of doing more on the PC side, especially as a way to support many slice receivers with a small FPGA, so there may eventually be a couple of different firmwares.

Although there are still many things that must and should happen first, I am still interested in the idea of greatly simplifying the native Hermes-Lite protocol and maintain compatibility with openHPSDR protocols only through a software layer. For example, we are wasting many bits by sending speaker audio in the current protocol. Also, although there are many nice features in the new protocol, it is heavy-weight and may not fit nicely in a small FPGA-minimalist environment. Maybe if a new native Hermes-Lite protocol becomes reality, we can revisit your VNA fast scan ideas. I'm not totally against that idea, but just thinking about what the tradeoffs are.

73,

Steve

KF7O

[Steve Haynal]

Hi Jim and Alan,

Thanks. One reason I'm glad to have done the CVA9 port is that most of the gigabit ethernet stuff is worked out. I hope the gigabit bring-up on the HL2 will be easier because of this. I still need to take a close look at the new receivers, but the 2:1 final decimation does sound nice for offloading computation.

73,

Steve

KF7O

[Graeme Jury]

Hello All,

Following this thread I am even more aware than ever of the huge amount of work going on behind the hardware development with the unseen software development. As always everything seems to require a compromise and affects everything else. I agree that it will be a good day when the work can be concentrated on the HL2 but would hope that the SDK etc. versions will not be completely abandoned as they are still a great piece of hardware and will always be a handy second rig.

Just to further complicate things while software developing I raise the radio that John Melton is currently working on, the piHPSDR. This radio is being primarily targeted at a RaspberryPi with a 7" touchscreen and an SDR to form a compact high performance self contained radio. The Hermes-Lite is a perfect partner for this software with a RaspberryPi to get a very low cost unit and I have it working on my bench in haywire fashion. John is supportive of the HL and although at present there are issues of TX power control not being the same as Hermes he will get to it in time and possibly come back to this group with some suggested compatibility changes. The software supports the old and new protocols. It would be a shame if so much processing was shifted to the computer that the RaspberryPi could not handle it and John's radio was lost to us. He is also keeping it desktop compatible so it will still run on a standard linux machine using a mouse rather than the touch.

Remotely operating my radio over my local lan via wifi is very important to me and I have a concern that gigabit ethernet may become an issue. I guess a DSP server could be written so that only audio spectrum data and control signals like filter switching or band change etc. are sent over the household wifi which would be easily handled by an 802.11g. Possibly not many others would want this but I would ask that when designing could you keep this in mind and if possible try to make this available. Currently with my SDK Hermes-Lite and Quisk, I can achieve this.

73, Graeme zl2apv

[Steve Haynal]

Hi Graeme,

For the foreseeable future, the plan is to use a Cyclone IV with 22K LE. This supports 3 slice receivers and should accommodate those with an interest in low bandwidth connections or low performance SBCs. Even if I do switch to a smaller FPGA, I would still want to support at least 1 RX/TX in a low bandwidth/low host performance mode. But there may be several variations of the firmware. Just as John Melton's good work has focused on remote access software such as ghpsdr in the past, but now is focused on the piHPSDR, I do not feel any obligation to focus on what interests the most people or what has been done in the past. This is still a hobby for me and I primarily pursue what interests me. This is open source and others are welcomed and encouraged to make derivative or complimentary work as well as support past work, but they must be prepared to do that on their own. For example, when I first started this project, I grabbed the RTL from the web and never asked a single question of the openHPSDR group. I'm starting to rant, but the point I have in mind is that most worthwhile open source starts by developers scratching their own itch and not by endlessly debating what should or shouldn't be.

[Graeme Jury]

Hi Steve,

Thanks for the response and the setting out of your future path. I guess it is a case of you know your direction but what you find on the way will determine the final destination if there is ever one. My XYL asks when are you going to be finished and I answer her "Hopefully never". I have no problem with you building for your personal interest as of course I am doing the same thing and standing on the shoulders of those who are doing the same work where I can.

73, Graeme

[Steve Haynal]

Hi Graeme,

My XYL has believed this project will never end for quite some time now...

I reread my last e-mail in this thread and don't think I came across clearly. So, I will try again. First, I sometimes feel overwhelmed when people say on this list that this, that or the other thing should be done. Often these suggestions are good, but I have limited time, and so acknowledge that I will end up focusing on what interests me most. 

Second, when people see something they want to happen in an open source project, often they must do the work to see it realized. Furthermore, they must often do this work with little help and assistance. We've seen examples of this in this project. The RadioBerry was done without any help. Jim felt an itch to cleanup the TX output and now we have a v1.42 frontend board and a TX preamp adopted in v2.0. Alan wanted to understand the openhpsdr protocol and now we have Spark SDR with great support for multiband skimming. Claudio felt that we should be more result and measurement driven, and now we have many pages on his website that have helped us improve the Hermes-Lite. John, you, Glenn, Andrew and others worked on PAs, TX and RX filters. We now have good LPF RX and TX filters on the HL2.0 and an external board that can be used with the HL2.0, as well as a better understanding of where to go in the future with filtering boards. Thank you to everyone for your help.

If Jim comes back with a working, clean and compact fast scan VNA functionality in the FPGA integrated with his existing VNA software, I would be very happy even though I lean towards a more software oriented approach. What matters most is what good work is actually done.

Along these lines, I plan to officially stop supporting Hermes-Lite 1.x and focus entirely on Hermes-Lite 2. Although there are still some rough edges, it is a working project with working firmware. Instead of maintaining a v2.0 fork on the current v1.x github site, I will start a new github site just for v2.0 and leave the v1.x site as is. If someone with experience would like to maintain or work on v1.x more, please let me know and I will give administrator rights.

[Sid Boyce]

Hi Steve,
I thought the v2.0 fork existed for quite some time.
I periodically do a pull to keep my local copy up to date.
slipstream:/usr/src/XXX/HL_V2.0/Hermes-Lite # git branch
master
* v2.0
slipstream:/usr/src/XXX/HL_V2.0/Hermes-Lite #
73 ... Sid.

On 22/11/16 16:55, Steve Haynal wrote:
> Hi Graeme,
>

> My XYL has believed this project will never end for quite some time now...
>
> I reread my last e-mail in this thread and don't think I came across
> clearly. So, I will try again. First, I sometimes feel overwhelmed
> when people say on this list that this, that or the other thing should
> be done. Often these suggestions are good, but I have limited time,
> and so acknowledge that I will end up focusing on what interests me

> most.Â

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

[Steve Haynal]

Hi Sid,

Yes, currently v2.0 is a fork in the v1.x repository. Probably by this weekend I will move v2.0 to its own github repository. This will separate the code and document churn of v2.0 from v1.x.

73,

Steve

KF7O

[Sid Boyce]

That's great, v1.x does not garner much interest and I know of guys who
have not shown any interest in building v1.x and are watching and
waiting for v2.0 to appear.
73 ... Sid.

On 22/11/16 18:48, Steve Haynal wrote:
> Hi Sid,
>
> Yes, currently v2.0 is a fork in the v1.x repository. Probably by this
> weekend I will move v2.0 to its own github repository. This will
> separate the code and document churn of v2.0 from v1.x.
>
> 73,
>
> Steve
> KF7O
>
>
> On Tuesday, November 22, 2016 at 10:24:05 AM UTC-8, Sid Boyce wrote:
>
> Hi Steve,
> I thought the v2.0 fork existed for quite some time.
> I periodically do a pull to keep my local copy up to date.
> slipstream:/usr/src/XXX/HL_V2.0/Hermes-Lite # git branch

> Â Â master

> * v2.0
> slipstream:/usr/src/XXX/HL_V2.0/Hermes-Lite #
> 73 ... Sid.
>
> On 22/11/16 16:55, Steve Haynal wrote:
> > Hi Graeme,
> >
> > My XYL has believed this project will never end for quite some
> time now...
> >
> > I reread my last e-mail in this thread and don't think I came
> across
> > clearly. So, I will try again. First, I sometimes feel overwhelmed
> > when people say on this list that this, that or the other thing
> should
> > be done. Often these suggestions are good, but I have limited time,
> > and so acknowledge that I will end up focusing on what interests me

> > most.Â

[James Ahlstrom]

Hello Steve and Group,

I now have my Quisk VNA program working with the current CVA9 firmware.  In the process of making it work, I learned a good bit about the firmware, and Phil verified my understanding.  I wrote some documentation (see below) to make life easier for other program authors.

There is still the issue of an arbitrary phase at power on.  Phil documents that the HPSDR hardware has a constant phase difference at startup, and that the calibration can be saved and reused.  But the Hermes-Lite starts at arbitrary phase.  This is not too surprising since the hardware is quite different.  Therefore you must re-calibrate at every power on, a minor inconvenience.  Phase is maintained if the hardware is not powered down or used as a transceiver.  I plan to study this further and report back here.  I am also working on a better PC-only scan so that there is no need to add anything to the firmware, but initial indications are that this is not possible.  Stay tuned.

Please replace two sections under VNA in the page "Hermes-Lite/wiki/Protocol-Coverage" with the following:

Basic VNA Operation

----------------------------

Hermes is placed into VNA mode by setting the VNA bit (C0 0b0001001x, C2[7]) to one, the Duplex bit (C0 0b00000000, C4[2]) to zero, the number of receivers to one, and the speed to 48ksps.  Then change the VNA frequency by sending the new Tx frequency (C0 0b0000001x).  When in VNA mode, the following are true:

     The Tx phase word is used for Rx.

     A sine wave is transmitted at the selected frequency. Do not send Tx samples, and do not turn the MOX bit on.

     Hermes returns microphone samples with the I/Q receiver samples, and VNA mode uses the least significant Mic bit to signal a frequency change.  This bit is always zero except at the time a frequency change command is received.

Basic VNA Software Flow

----------------------------------

     Turn VNA mode on.

     Set the frequency.

     Detect the frequency change in the least significant bit of the Mic samples.

     Wait for the frequency change to take effect, and the receiver signal to stabilize.

     Collect and average N number of IQ samples from the receiver. Since Rx and Tx are in lock step, these represent a phase difference between Rx and Tx, as well as a magnitude.

     Repeat for all frequencies of interest.

Jim

N2ADR

[in3otd]

Great work Jim,
I look forward to try Quisk VNA with my CV A9-based H-L.
I took a quick look at the Hermes and Hermes-Lite FW code and, as you wrote before, it seems that the TX and RX cordics phase is never initialized, so will have a random value at every power up. If this is really the case, I wonder why this is not a problem for other HWs.
Why two separate cordics are used for TX and RX in the VNA mode? Could just a single one be used? (unless the VNA mode supports some exotic stuff, like measurements on frequency-translating devices - mixer, transverters, etc.)

73 de Claudio IN3OTD / DK1CG

[Steve Haynal]

Hi Jim,

Thanks for the great work. I hope to be able to help out with any RTL changes such as initializing phase in a few months after the HL2 hardware shows life, but feel free to make your own changes.

Does anyone want to get involved in documentation and help Jim out by including his notes and changes on the wiki? To make helping with documentation as easy as possible, all that is needed to edit the wiki is a free github login. The wiki is at:

https://github.com/softerhardware/Hermes-Lite/wiki

Thanks and 73,

Steve

KF7O

[in3otd]

On Friday, November 25, 2016 at 8:00:25 PM UTC+1, Steve Haynal wrote:
[snip

Does anyone want to get involved in documentation and help Jim out by including his notes and changes on the wiki?

VNA documentation on the Wiki updated, please check for any added mistake, hi.

[James Ahlstrom]

Hello Claudio,

The HiQSDR does use a single cordic for VNA mode.  But the cordics have a built-in multiplication, so when you change to one cordic you must add two multipliers.  I am concerned to keep the VNA changes small because they may result in a decrease in the max number of receivers.  I am exploring the idea of synchronizing the Tx and Rx cordics by setting the phase to zero when the frequency is zero.  Then the PC just sends a zero frequency when VNA starts.  This requires almost no additional logic in the firmware.  Stay tuned.

There is a further problem with Hermes-Lite.  The HiQSDR only has one receiver, but HL has many.  Unless we are careful, the VNA changes will be incorporated into multiple receivers even though they need only be in the first.  Just another detail for the generator statement that creates the receivers.

Jim

N2ADR

[Phil Harman]

Hi Jim,

Thanks for documenting this, well down my 'to do' list I'm afraid.  I'd like to suggest folks have a look at the VNA code that Alex, VE3NEA, of cw skimmer fame wrote for the Hermes board (http://www.dxatlas.com/). This has a feature that I've not come across before in  a VNA.

If you measure a conventional leaded capacitor at a number of frequencies then the apparent capacitance changes due to the series inductance of the capacitor leads. Alex's code correctly models this as a fixed capacitance in series with an inductance.  Same result for any device with lead inductance or shunt capacitance. 

I gather the math to do this was far from trivial. 

73 Phil...VK6PH 

[James Ahlstrom]

Hello Phil,

Yes, I have Alex's program HamVNA here and I like it very much.  Besides the LCR fitting you mentioned, it also plots Smith charts.

Jim

N2ADR

[James Ahlstrom]

Hello Group,

The current Hermes protocol supports a VNA mode where the scanning of frequencies is controlled by the PC.  I have been testing this with my newly-working VNA software.  Here is what I found out.

Quisk VNA tends to run very wide screen, and I am using a graph width of 1536 points.  The default width of HamVNA is 600 points.  For Hermes-Lite, the time between sending a frequency change request and receiving the ACK in the Mic bit is 1.67 milliseconds.  If I print the samples after changing the frequency, I see that a change in the I/Q data occurs after 70 samples at 48000 sps, or an additional delay of 1.5 milliseconds.  This delay is caused by the two CIC filters and the FIR filter following the cordic.  This will make it difficult to scan faster than 2 milliseconds, or two seconds for 1000 points.  My software scans 1536 points in 8.5 seconds, or 5.5 msec per point.  HamVNA scans 600 points in 3.3 seconds, or 5.5 msec per point.  So for 1000 points, maybe we can reduce this to two or three seconds per update.

In contrast, my HiQSDR software scans at about 100 microsecond per point, and updates the screen six times a second.  This gives a continuous display, useful for tuning filters, for example.  Since the FPGA is changing the frequency, there is no need to wait for the PC to receive the ACK bit.  And the HiQSDR software in VNA mode uses the data from the cordic without any subsequent filters.  Thus the much faster speed.  The software on the PC side is much simpler, because there is no need to figure out what sample came from what frequency.

I do not plan on pursuing a PC-scan solution for HL because I think it is hopeless.  I also don't plan on releasing my PC-scan VNA software for HL because I think HamVNA is better.

I do plan on pursuing an FPGA-scan solution for HL.  I will have to work on the CVA9 and port this to Cyclone4 when the HLv2 is available.  Until then we won't be able to judge how much resource the FPGA-scan uses, but I will keep resource usage to a minimum.  Of course, I will make the code available to Phil and Alex if I can make it work.

Jim

N2ADR

[Steve Haynal]

Hi Jim,

Thanks for working on this. Solid VNA functionality will be useful to hams as well as others. I can imagine some manufacturers of open source hardware like Adafruit or Seeed studio could be more interested in picking the HL2 up if it is also a good VNA. Perhaps one could buy a VNA, but then a user could add components to the PCB to realize a QRP transceiver.

I think your Hermes-Lite VNA latency numbers are so dismal because of the way the protocol currently works. For a single RX, packets are arriving back at audio sampling speed intervals, not the fastest that the network can support. There is only support for one outstanding transaction, and so frequency change requests can not be pipelined. The full final FIR filter is in play and adds latency. I think if there were a way to quickly request change frequency and have just a small set of VNA samples returned from the CIC output with no FIR delay and not in lockstep with some audio sampling frequency, then a software oriented approach could approach the speeds you see with the HiQSDR, or at least be fast enough for no delay in visual perception. Pipelining transactions could help even more. We should be able to get closer to the latency numbers I measured for ICMP packets with ping flood, which are similar to what you see with the HiQSDR. But these type of protocol changes are probably more work than adding fast frequency sweep to the existing protocol. Still, they are inline with a side channel network access I want to eventually add to the Hermes-Lite 2 firmware. Maybe when that is in place, I can revisit software-oriented VNA functionality as I do not think it is hopeless, but for right now, your fast frequency sweep sounds like a great way to go.

73,

Steve

KF7O

[Steve Haynal]

Hi Jim,

One other thought. How hard would it be to port your entire HiQSDR firmware over to work with the MAC RTL on the CVA9? It would be a small step from the CVA9 with gigabit to the Hermes-Lite 2.0. This would be an alternate stable firmware with fast VNA support for users.

73,

Steve

KF7O

[James Ahlstrom]

Hello Steve,

Porting the HiQSDR firmware to the CVA9 would be difficult because the HiQSDR uses an Ethernet controller with a memory interface to the FPGA, and the CVA9 uses a MAC that must operate in real time.  I don't think alternate firmware is a good idea because I anticipate that most hams would be unable to deal with the Quartus software, and would dislike buying a programmer.  And the HiQSDR does not support the PC-scan VNA mode that HamVNA uses.  I think we must support the Hermes protocol as it exists so that all Hermes software is available to HL.  The question is whether we want to port the New Ethernet Hermes software.  Probably we will be forced to do so as more good software becomes available for that protocol.

My plan is to support transceiver mode and two VNA modes, namely PC-scan and FPGA-scan.  In addition, I will add sync to the PC-scan so that calibrations can be saved.  Don't get too worried about the resources until I can measure what it costs.

While we are on the subject, I need a way to send three parameters to the HL: VNA start frequency, frequency to add for each scan point, and the number of scan point to send.  I am using the Tx frequency as the start frequency, and the Rx1 frequency as the amount to add.  That leaves scan points.  I plan to use the C0[7:1] == 0001_001,   C3 and C4 for this.  This is 16 bits that are used in Alex and unused in Hermes.  Is that OK?

Jim

N2ADR

[Alan Hopper]

Jim, Steve,

It strikes me from recent discussions that there is an argument for multiple firmware versions, for the pihpsdr user everything wants to be done on the fpga, for the skimmer with a pc, network usage can be traded for more receivers, for even more extreme use dfc is desirable. The fpga is a powerful resource and if using it is the best way to create a vna then we should do it that way, Jim's solution sounds great, but why compromise the radio functionality by trying to squeeze everything in at once, we should make the most of the p in fpga. If we could have a common lightweight and robust fpga code download option then pc progams could download the firmware they expect on the fly i.e. the vna program could upload optimised code if it detects it is not already installed, when you next fire up your skimmer it might then replace the firmware with a dfc version.   My guess is the number of fpga hobbyists is growing fast (I recently discovered that two separate friend's teenage sons are playing with fpgas) so over the life of the HL2 hopefully there will be many things done with the fpga code.  Obviously stage one is to just get HL2 working with existing software and protocols but I can see a lot of value in easy reprogramming.  I'm guessing the red pitya does something along these lines.

Steve, is there a plan for network programming/ boot-loader stuff? I know you described an option when the max10 was in the picture. 

73 Alan M0NNB 

On Tuesday, November 29, 2016 at 5:58:36 PM UTC, James Ahlstrom wrote

[Steve Haynal]

Hi Alan and Jim,

C0[7:1], C3 and C4 should be fine as long as VNA can be disabled. My only worry is that someone using Alex-aware software with the HL may start some VNA scan.

It is too bad that the HiQSDR firmware can't be connected easily to the new gigabit MAC. I was aware of the external controller you are using, but was hoping that with a little bit of memory glue inside the FPGA everything could work.

I'm supportive of multiple firmware versions. The challenge is to find volunteers with skills and persistence to maintain and support a fork. I imagine I can help with two versions. One very conservative version based on the existing firmware which support the old protocol. And another with more experimental features.

There is functionality to reprogram the FPGA over the network in the openhpsdr firmware. The original BeMicro SDK-only HL had that and it worked fine. When the BeMicro CV came along, I could never get that functionality to work on the Cyclone V architecture and actually corrupted some configuration EEPROMs beyond repair. I had to replace the EEPROMs on my BeMicro CVs. I removed the functionality due to that experience. The HL2 uses a Cyclone IV architecture so this is no longer an issue. I will either reinstate the old functionality or provide similar functionality over the side channel interface.

73,

Steve

KF7O

[James Ahlstrom]

Hello Steve,

C0[7:1], C3 and C4 should be fine as long as VNA can be disabled. My only worry is that someone using Alex-aware software with the HL may start some VNA scan.

All bytes but one are currently used in the Protocol, but I need two bytes in the same C0 index..  I thought that since C0==1001x   C3 and C4 are Alex, they were available for any Hermes.  So this was my plan:

Plan A:

  For {C3, C4}  !=  0     the FPGA starts VNA mode and scans the frequencies.

I am not sure what you mean by "VNA can be disabled".  Is this more like what you want?

Plan B:

  For the bit C2[7] VNA==0  operate as a transceiver (no VNA at all).

  Else

    If {C3, C4} == 0  the PC scans the frequencies, as in the current firmware.

    else                   the FPGA scans the frequencies (new code)

Note that the new code must support the current scheme of the PC scanning frequencies as used in HamVNA, as well as the new FPGA scan.  Is Plan B OK?

Jim

N2ADR

[John Williams]

I am not sure if this is pertinent, but on the current firmware, we use some alex features to read forward and reverse power. It uses a few lines that are fed from a board I built. The board is called Power2 and is on my github. There are probably a handful of users so it would not be good to disrupt this on the current V1.2 firmware. On the V2 board, Steve is planning an different implementation.

John

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Haynal]

Hi Jim,

I like your Plan B. As long as C2[6]==0 (Alex - manual HPF/LPF filter select is disabled), you should be able to repurpose C3 and C4 on any SDR using the openHPSDR protocol. We don't use the Alex_* signals in the HL and they are just dangling. I have no plans to use them. If your VNA mode is used on an openHPSDR SDR with Alex support, is there any reason why someone would want to enable Alex manual filters while using the VNA? I can't think of a reason but I have never used Alex. 

One of my frustrations with the openHPSDR protocol is that it is not extensible. I really want to add a side channel that is a simple memory "peek" and "poke" on a different ethernet port not bound to the timing of the main stream so that all these control values can be set via that channel. If we have an ample memory map, we can easily add and experiment with new functionality. 

73,

Steve

KF7O

[Steve Haynal]

Hi John,

Thanks for bringing this up. Jim is repurposing some of the Alex commands from PC to SDR. The ADC values you are using for power and SWR are in a different packet from SDR to PC and will not be impacted by his changes.

73,

Steve

KF7O

[Alan Hopper]

Steve,

that is good to hear.  Thanks for the reminder of the cv issue, I was thinking of trying to re enable it in the cva9 but will give it a miss with that warning!

73 Alan M0NNB

[James Ahlstrom]

Hello Group,

The firmware to scan VNA frequencies is done.  I am just working through a confusing 6% error in the phase, but it is probably in my Python code, not the Verilog.  Here is a measurement of the resource usage.  I am testing with the CVA9 and three receivers.  Adding the scanner changes the total resources as follows:

                                  Original       With Scanner

Logic Util.                        8177               8384

Total Registers              17276             17556

Memory                       535040           535040

DSP Blocks                         56                   56

More interesting is the comparison with the resources need by a receiver.  Most of the logic is in the scanner module.

                   LC Comb.    LC Reg.        Memory        DSP

Rx1                   2904         3785          110592          16

Rx2                   2580         3394            73728          16

Rx0                   2617         3394            73728          16

Scanner              223           185                    0            0

We see that the scanner logic is more than ten times smaller than a receiver and uses no memory or DSP.  That is because it uses the first receiver to do most of the calculations.  It is interesting that the three receivers use a slightly different amount of resources even though the code is the same.  The saving in receiver memory after Rx1 is due to reusing the filter coefficient ROM.

As a bonus, the new logic also synchronizes the Rx and Tx cordics for the PC scanner.  I would like to add this code to HL once I test it a bit more.

Jim

N2ADR

[Graeme Jury]

Hi Jim,

Congratulations! These results probably have exceeded even your expectations and I hope will be valuable to the Hermes guys too. It would be nice to be giving something back after taking from them for so long.

Thanks for your tenacity,

73 de Graeme zl2apv

[Steve Haynal]

Hi Jim,

Great work! The added resource utilization looks very low. I look forward to using it.

Do you want write permission to the v1.x github repository? You could then check in your changes directly.

73,

Steve

KF7O

[James Ahlstrom]

Hello Steve,

On Tuesday, December 6, 2016 at 12:42:19 AM UTC-5, Steve Haynal wrote:

Do you want write permission to the v1.x github repository? You could then check in your changes directly.

Yes, I think that is the best plan.  I don't know git very well, but I am using it.

Jim

N2ADR 

[Steve Haynal]

Hi Jim,

I've made you a github collaborator and hopefully you received the collaborator request. You should be able to push your own changes to the repository. 

The basics of git are not too hard to learn. I prefer git over other systems I've used. There is some helpful information here.

Thanks and 73,

Steve

KF7O

[James Ahlstrom]

Hello Group,

I pushed my VNA changes to github, and changed the VNA documentation on the wiki   https://github.com/softerhardware/Hermes-Lite/wiki/Protocol-Coverage.  I am still learning git, so if there are any changes or criticisms, please complain to me.

The changed firmware source files are cordic.v cpl_cordic.v, receiver.v (all trivial changes), hermes_lite_core.v (minor changes) and vna_scanner.v (new file).   I changed the Hermes_serialno to 32.  I left all the old bitfiles unchanged, and added new bitfiles in bitfiles/20161207.  There are quite a few firmware versions for different BeMicros, clocks, etc.  I only compiled code for CVA9 and SDK.  I can only test the CVA9.  I am happy to compile more bitfiles for the version you need, just ask.  Please specify the BeMicro, clock and TxDac or IAMP.

The new firmware fully supports the Hermes VNA protocol, and there should be no change in the operation of HamVNA or OpenHPSDR VNA.  The new code synchronizes the Rx and Tx cordics, but I have some evidence that after a power cycle, HL can start with a different phase.  So there may be a second source of phase difference.  For now it is safest to calibrate after every power up.  I am testing with HamVNA and sometimes it can fail to start.  Pushing Connect/Disconnect may solve the problem, but it may be necessary to cycle power.  This happened with the old firmware too, and I don't think it is different with the new firmware.  On exit, HamVNA leaves HL in VNA mode, and so HL continues to send data even though there is no one to read it.  This is a problem, so press "Disconnect" before you exit HamVNA.  I heartily recommend HamVNA, as it displays Smith Charts and fits an RCL network to the VNA data.

I will soon release a new Quisk VNA that can scan with the new VNA method.  I plan to contact the author of HamVNA and encourage him to add support for the new method, but I doubt that will happen until HL2 is finished and commonly available.

Jim

N2ADR

[Graeme Jury]

Hello Jim,

Thanks for that great work. I have an SDK and will be happy to test on that platform for you but it will have to wait until Monday as we are just about to depart in our caravan for the weekend. I have not used  HamVNA and I suspect that it is windows only software. Unfortunately I am Linux only here but I can give Wine a go.

The VNA feature will set the Hermes-Lite apart from other low cost sdr radios and will bring an instrument only dreamed of in past years onto the workbench of the keen experimenter.

73, Graeme zl2apv

[Steve Haynal]

Thanks Jim!

73,

Steve

KF7O

[Graeme Jury]

Hello Jim,

I have loaded HL 32 onto my SDK and run VNA with Quisk. It all works although gets quite noisy above 15 MHz or so. It keeps running after I press the run button to stop it but I can get a good plot of a filter and have attached a sample of a 1/2 wave filter for 80 M band and it is a good reproduction of the performance I get with miniVNA or HiQSDR

73, Graeme zl2apv

[James Ahlstrom]

Hello Graeme,

Thanks for testing this.  Please add attenuators because you are clipping, and the ADC is overloaded.  There should be no RF output after you release the Run button.  But the graph and display will continue to work without the Run button because they are using the saved data.

Jim

N2ADR

[Graeme Jury]

Hi Jim,

Thanks for the tip on clipping. I had 10 dB in both the Rx and Tx leads and when calibrating and testing with a straight through connector the clip warning was not there but when I ran it through the filter it clipped so I will try another 6 dB as I must be very close to the edge. I now understand about the run button and RF out so thanks for that. I also tested the build 32 Hermes-Lite with John Melton's piHPSDR and it worked perfectly on that radio too so no regressions there.

73, Graeme

[James Ahlstrom]

Thanks for the testing Graeme.  It is very valuable to have someone else looking at this.

Jim

N2ADR

[Sid Boyce]

Hi all,
I changed the subject for reasons of clarity.

I have been using the Pi 3 based pihpsdr with Hermes-Lite for quite a while.

There are perhaps incompatibilities that would account for some of the
switches and rotary encoders not behaving as expected.
From the Menu and touch screen there are no problems.

USB Gigabit Ethernet supports Hermes-Lite with the new protocol.

John Williams supplied the OC parameters so the 5W PA/LPF band
switching works.

I also have an ODROID-C2 running quisk or the pihpsdr application under
Ubuntu ARM 16.04.1 64-bit, 7 inch touch screen with built-in HDMI audio,
AOK with Hermes-Lite.
The problem with the ODROID-C2 is that it doesn't have the number of
edge triggered GPIO's required. So It only has room for the VFO encoder.

There are 2 GPIO extender chips -- MCP23017 being explored by John and
SX1509 board from Sparkfun used by Rick (N1GP).
They both seem to regard the MCP23017 as a better solution so I bought 2
and sent one on to Rick.

John has the ODROID-C1+, a PINE64 and a PINE A64+ working on and Rick
has a Pi 3 and recently got an ODROID-C2.

The Raspberry Pi 3 tends to struggle at times, most notably if I am
doing an online upgrade at the same time as pihpsdr is running.
On the other hand, the more powerful ODROID-C2 doesn't miss a beat
unless I am doing a huge compile like qt5 at the same time pihpsdr is
running.

openSUSE and Fedora have 64-bit Linux distros for the Pi 3.
I downloaded openSUSE but have not yet tried it, may be in a couple of
months when it may be more mature though there have been no reports of
problems with their latest builds 2016.11.25-Build1.14 to -Build1.18
released 28th. December.
73 ... Sid.

On 19/11/16 22:15, Graeme Jury wrote:
> Hello All,
>
> Following this thread I am even more aware than ever of the huge
> amount of work going on behind the hardware development with the
> unseen software development. As always everything seems to require a
> compromise and affects everything else. I agree that it will be a good
> day when the work can be concentrated on the HL2 but would hope that
> the SDK etc. versions will not be completely abandoned as they are
> still a great piece of hardware and will always be a handy second rig.
>
> Just to further complicate things while software developing I raise
> the radio that John Melton is currently working on, the piHPSDR. This
> radio is being primarily targeted at a RaspberryPi with a 7"
> touchscreen and an SDR to form a compact high performance self
> contained radio. The Hermes-Lite is a perfect partner for this
> software with a RaspberryPi to get a very low cost unit and I have it
> working on my bench in haywire fashion. John is supportive of the HL
> and although at present there are issues of TX power control not being
> the same as Hermes he will get to it in time and possibly come back to
> this group with some suggested compatibility changes. The software
> supports the old and new protocols. It would be a shame if so much
> processing was shifted to the computer that the RaspberryPi could not
> handle it and John's radio was lost to us. He is also keeping it
> desktop compatible so it will still run on a standard linux machine
> using a mouse rather than the touch.
>
> Remotely operating my radio over my local lan via wifi is very
> important to me and I have a concern that gigabit ethernet may become
> an issue. I guess a DSP server could be written so that only audio
> spectrum data and control signals like filter switching or band change
> etc. are sent over the household wifi which would be easily handled by
> an 802.11g. Possibly not many others would want this but I would ask
> that when designing could you keep this in mind and if possible try to
> make this available. Currently with my SDK Hermes-Lite and Quisk, I
> can achieve this.
>
> 73, Graeme zl2apv

>
>
>
> On Sunday, November 20, 2016 at 9:18:51 AM UTC+13, Steve Haynal wrote:
>
> Hi Jim,
>

> The CVA9 firmware does work, but in terms of timing closure for
> many >4 receivers (it seems brittle when attempting anything new
> in the RTL) and testing that all functionality (VNA, etc.) is
> covered, I still think it has been neglected.
>
> Regarding SBCs, many are now quite powerful, with multicore CPUs
> and GPUs that support OpenCL. They may be able to do more than
> your old Atom desktop. Still, I don't want to reduce the size of
> the FPGA such that it can not fit a final FIR filter. I would want
> people to be able to use a firmware that does do most of the
> processing on the FPGA even if it is only for 1 receiver and 1
> transmitter with a SBC. But I want and am interested in the
> possibility of doing more on the PC side, especially as a way to
> support many slice receivers with a small FPGA, so there may
> eventually be a couple of different firmwares.
>
> Although there are still many things that must and should happen
> first, I am still interested in the idea of greatly simplifying
> the native Hermes-Lite protocol and maintain compatibility with
> openHPSDR protocols only through a software layer. For example, we
> are wasting many bits by sending speaker audio in the current
> protocol. Also, although there are many nice features in the new
> protocol, it is heavy-weight and may not fit nicely in a small
> FPGA-minimalist environment. Maybe if a new native Hermes-Lite
> protocol becomes reality, we can revisit your VNA fast scan ideas.
> I'm not totally against that idea, but just thinking about what
> the tradeoffs are.
>
> 73,
>
> Steve
> KF7O
>
>
>
> Â
>
> On Saturday, November 19, 2016 at 11:19:20 AM UTC-8, James
> Ahlstrom wrote:
>
> Hello Steve,
>
> I don't think it is correct to say the CVA9 firmware has been
> neglected. Â The CVA9 firmware works fine. Â Now that I am
> looking more at the firmware, I see that you implemented code
> for four versions of BeMicro, two AD9866 interfaces (full word
> and nibble), and several clocks. Â My hat is off to you. Â It
> will be a relief to get back to a single RTL for HL V2, but
> for now, great work Steve!
>
> I see your point about wanting to do most work in the PC, but
> I would argue for a careful division. Â Quisk always offered
> sample rates up to 960ksps, but my old Intel Atom desktop PC
> would choke on the higher rates. Â HL will be popular with the
> single board computer crowd, and I question whether an ARM
> processor can do much with a Gig data stream. Â For example, I
> would not move the final FIR (after the Rx CIC filters) to the
> PC because the operation is standard and unlikely to change,
> and it results in 8 times greater bandwidth usage and a burden
> on the PC that is easily avoided.
>
> I will definitely pursue a PC-only VNA. Â For now, that is
> what we have and I want to understand it and make it work.
> Â But I doubt it can be great within the current protocol.
> Â We could extend the protocol but I think we should try to
> maintain compatibility with Phil's "old" protocol, and try to
> make it easy for him to backport any changes he wants.

>
> Jim
> N2ADR
>
> --
> You received this message because you are subscribed to the Google
> Groups "Hermes-Lite" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to hermes-lite...@googlegroups.com

> <mailto:hermes-lite...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

[Graeme Jury]

Hi Sid,

Some interesting info on one of the Raspberry Pi deficiencies and an improvement here This could allow new protocol operation.

73, Graeme zl2apv

> <mailto:hermes-lite+unsub...@googlegroups.com>.

[Sid Boyce]

Hi Graeme,
My Pi 3 based pihpsdr uses a Plugable USB 2.0 Gigabit Ethernet but there
are other attributes that make the ODROID-C2 a better fit.
It runs the new Ethernet protocol with CVA9 Hermes-Lite.

The ODROID-C2 has a quad-core CPU that runs at 1.54GHZ, Gigabit Ethernet
not on the USB bus and 2x the Memory of the Pi 3.
73 ... Sid.

On 01/01/17 04:48, Graeme Jury wrote:
> Hi Sid,
>
> Some interesting info on one of the Raspberry Pi deficiencies and an
> improvement here

> <http://www.jeffgeerling.com/blogs/jeff-geerling/getting-gigabit-networking>

> This could allow new protocol operation.
>
> 73, Graeme zl2apv
>
> On Friday, December 30, 2016 at 12:05:13 PM UTC+13, Sid Boyce wrote:
>
> Hi all,
> I changed the subject for reasons of clarity.
>
> I have been using the Pi 3 based pihpsdr with Hermes-Lite for
> quite a while.
>
> There are perhaps incompatibilities that would account for some of
> the
> switches and rotary encoders not behaving as expected.

> Â From the Menu and touch screen there are no problems.
>
> USB Gigabit Ethernet  supports Hermes-Lite with the new protocol.
>
> John Williams supplied the OC parameters so the  5W PA/LPF band

> switching works.
>
> I also have an ODROID-C2 running quisk or the pihpsdr application
> under
> Ubuntu ARM 16.04.1 64-bit, 7 inch touch screen with built-in HDMI
> audio,
> AOK with Hermes-Lite.
> The problem with the ODROID-C2 is that it doesn't have the number of
> edge triggered GPIO's required. So It only has room for the VFO
> encoder.
>

> There are 2 GPIO extender chips -- MCP23017 being explored  by
> John and Â

> SX1509 board from Sparkfun used by Rick (N1GP).
> They both seem to regard the MCP23017 as a better solution so I
> bought 2
> and sent one on to Rick.
>

> John has the ODROID-C1+, a  PINE64 and a PINE A64+ working on and

> > Â Â Hi Jim,
> >
> > Â Â The CVA9 firmware does work, but in terms of timing
> closure for
> > Â Â many >4 receivers (it seems brittle when attempting
> anything new
> > Â Â in the RTL) and testing that all functionality (VNA, etc.) is
> > Â Â covered, I still think it has been neglected.
> >
> > Â Â Regarding SBCs, many are now quite powerful, with
> multicore CPUs
> > Â Â and GPUs that support OpenCL. They may be able to do more
> than
> > Â Â your old Atom desktop. Still, I don't want to reduce the
> size of
> > Â Â the FPGA such that it can not fit a final FIR filter. I
> would want
> > Â Â people to be able to use a firmware that does do most of the
> > Â Â processing on the FPGA even if it is only for 1 receiver
> and 1
> > Â Â transmitter with a SBC. But I want and am interested in the
> > Â Â possibility of doing more on the PC side, especially as a
> way to
> > Â Â support many slice receivers with a small FPGA, so there may
> > Â Â eventually be a couple of different firmwares.
> >
> > Â Â Although there are still many things that must and should
> happen
> > Â Â first, I am still interested in the idea of greatly
> simplifying
> > Â Â the native Hermes-Lite protocol and maintain compatibility
> with
> > Â Â openHPSDR protocols only through a software layer. For
> example, we
> > Â Â are wasting many bits by sending speaker audio in the current
> > Â Â protocol. Also, although there are many nice features in
> the new
> > Â Â protocol, it is heavy-weight and may not fit nicely in a
> small
> > Â Â FPGA-minimalist environment. Maybe if a new native
> Hermes-Lite
> > Â Â protocol becomes reality, we can revisit your VNA fast
> scan ideas.
> > Â Â I'm not totally against that idea, but just thinking about
> what
> > Â Â the tradeoffs are.
> >
> > Â Â 73,
> >
> > Â Â Steve
> > Â Â KF7O
> >
> >
> >
> >   Â
> >
> > Â Â On Saturday, November 19, 2016 at 11:19:20 AM UTC-8, James
> > Â Â Ahlstrom wrote:
> >
> > Â Â Â Â Hello Steve,
> >
> > Â Â Â Â I don't think it is correct to say the CVA9 firmware
> has been
> >     neglected. Â The CVA9 firmware works fine. Â Now
> that I am
> > Â Â Â Â looking more at the firmware, I see that you
> implemented code
> > Â Â Â Â for four versions of BeMicro, two AD9866 interfaces
> (full word
> >     and nibble), and several clocks. Â My hat is off to
> you. Â It
> > Â Â Â Â will be a relief to get back to a single RTL for HL
> V2, but
> > Â Â Â Â for now, great work Steve!
> >
> > Â Â Â Â I see your point about wanting to do most work in
> the PC, but
> >     I would argue for a careful division. Â Quisk
> always offered
> > Â Â Â Â sample rates up to 960ksps, but my old Intel Atom
> desktop PC
> >     would choke on the higher rates. Â HL will be
> popular with the
> > Â Â Â Â single board computer crowd, and I question whether
> an ARM
> >     processor can do much with a Gig data stream. Â For
> example, I
> > Â Â Â Â would not move the final FIR (after the Rx CIC
> filters) to the
> > Â Â Â Â PC because the operation is standard and unlikely to
> change,
> > Â Â Â Â and it results in 8 times greater bandwidth usage
> and a burden
> > Â Â Â Â on the PC that is easily avoided.
> >
> >     I will definitely pursue a PC-only VNA. Â For now,
> that is
> > Â Â Â Â what we have and I want to understand it and make it
> work.
> >     Â But I doubt it can be great within the current
> protocol.
> >     Â We could extend the protocol but I think we
> should try to
> > Â Â Â Â maintain compatibility with Phil's "old" protocol,
> and try to
> > Â Â Â Â make it easy for him to backport any changes he wants.
> >
> > Â Â Â Â Jim
> > Â Â Â Â N2ADR

> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Hermes-Lite" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send

> > an email to hermes-lite...@googlegroups.com <javascript:>
> > <mailto:hermes-lite...@googlegroups.com <javascript:>>.

> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.