Price for BeMicro CVA9 Posted

[Steve Haynal]

Arrow has posted a $149 price for the BeMicro CVA9 although there is no stock yet. (Go to www.arrow.com and search for bemicro.) I am *amazed* that they are selling it for this price as A9 FPGA sells for $228. The resources on this FPGA are a big jump from the BeMicro's. The A9 has 684 18 bit multipliers, and 10x the number of logic elements. One could definitely fit 12 receivers on this and do WSPR for all the bands below 30 MHz. With the gigabit ethernet port, you could do wideband experiments also. It is nice to have options for the DSP engine with the Hermes-Lite. 

Although it costs more than the BeMicro CV, this is by far the lowest price per FPGA resources I have seen in a commercially available FPGA board. Please let me know if you know of any similar or better deals. 

73,

Steve

KF7O

[John Laur KF5SAB]

Does anyone have any confirmation that the chip on the BeMicro CV A9 will be supported by the Quartus II Web Edition? They still advertise that the 5CEA9 parts are excluded.

For a hobbyist, that means that we either spend a couple thousand bucks for the software, rely on time limited trials, or have to rely on others to build and debug. That does somewhat mitigate the low price for the hardware at least from a developer perspective.

Perhaps Altera will lessen the restrictions on Web Edition when this board becomes available. I would encourage anyone who has an actual feedback path to Arrow/Altera ask about this if possible.

73, John KF5SAB

[Alan Hopper]

Steve,

great project, I ordered a CVA9 last week purely with a view to multi rx wspr reception!  I clicked on the 'give me a quote' button on the arrow site before the price was published and was quoted a an unbelievably low price, I'm hoping they stick to it.  I'm relying on a further piece of luck and a change of heart from Altera on free tool support.  I would like to add my name to any group buys for either pcbs or assembled units in affordable range of the uk.

73,

Alan

M6NNB 

[Steve Haynal]

I have no confirmation that the CVA9 will be supported in the free Quartus edition. Altera may offer a 30-day evaluation license, or include a device-specific license with the BeMicro CVA9, or someone on this list may have access to a full version of Quartus. I'm not sure I'd want to wait for hours for the single-processor free version of Quartus to compile a large design for the CVA9...

73,

Steve

KF7O

 

[John Laur KF5SAB]

FWIW if you enable talkback for Web Edition it does enable parallel compilation. I believe this was added in 13 or 13.1 along with SignalTap. The BeScope demo board uses SignalTap I believe. Not a lot of fuss was made about it, but it's obviously very helpful. I ran a build of Angelia 4.2 which and it built in 10m17s on a 6 core i7 980 24GB. This is about 20K LE.

73, John KF5SAB

[Steve Haynal]

Thanks! That is good to know.

73 Steve

[Alan Hopper]

I just got an email from arrow saying that my cva9 is about to ship, they are now listed as in stock on the website.

Alan M6NNB 

[Steve Haynal]

That is great news. I want to use one to protoype and test gigabit ethernet. They aren't listed as in stock yet on the US arrow site. Which site did you find them at?

73,

Steve

KF7O

[Alan Hopper]

https://parts.arrow.com/item/detail/arrow-development-tools/bemicrocva9#FR2n

just got a mail to say it has shipped, great news that you are going to use one

[Sid Boyce]

Hi Alan,
It says in stock $149 but does not have a button to add to cart or buy.

I'll try chat with them later.
73 ... Sid.

--
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.

-- 
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

[John Laur]

The free Web Edition license of Quartus II did not formerly support
the larger FPGA used on the CV A9. Please let us know if it works
properly or not.
https://www.altera.com/en_US/pdfs/literature/po/ss_quartussevswe.pdf I
really hope Altera has exempted it or produced a special model # for
this part that will allow the freely available edition to work,
otherwise this board is not goign to get the traction it deserves.

By the way they are doing a Max10 BeMicro as well with USB 3.0
http://parts.arrow.com/item/detail/arrow-development-tools/bemicromax10
I don't know if that has been discussed here.

73, John K5IT

[Steve Haynal]

If I recall correctly, it was mentioned on the sdrstick group that the free Quartus 15.0 would support the CV A9 starting around May or June.

The documentation on the Arrow site does not have the pinout for the 80-pin edge connector. There is a note to refer to the CV documentation. Does anyone know if the pins used on the 80-pin are really the same as the CV? There were differences between the SDK and CV.

We've discussed the BeMicro MAX10 in the past. The MAX10 part on it doesn't have enough FPGA resources to do what we need. Where did you read about USB 3.0? I thought it was 2.0 only.

Here is another FPGA board that was just announced. This is the first <$100 board I've seen with an Altera SoC (ARM+FPGA). No high speed connection possibilities though. In the Intel press release, they said they would continue with Altera's use of ARM processors... Here is another.

 

73,

Steve

KF7O

 

On Wednesday, June 3, 2015 at 8:17:09 AM UTC-7, John Laur KF5SAB wrote:

The free Web Edition license of Quartus II did not formerly support
the larger FPGA used on the CV A9. Please let us know if it works
properly or not.
https://www.altera.com/en_US/pdfs/literature/po/ss_quartussevswe.pdf I
really hope Altera has exempted it or produced a special model # for
this part that will allow the freely available edition to work,
otherwise this board is not goign to get the traction it deserves.

By the way they are doing a Max10 BeMicro as well with USB 3.0
http://parts.arrow.com/item/detail/arrow-development-tools/bemicromax10
I don't know if that has been discussed here.

73, John K5IT

[Sid Boyce]

I went back to arrow last night and there were something like 150 CV A9's available, my order has been shipped.
73 ... Sid.

On 03/06/15 12:33, Sid Boyce wrote:

Hi Alan,
It says in stock $149 but does not have a button to add to cart or buy.

I'll try chat with them later.
73 ... Sid.

On 03/06/15 07:32, Alan Hopper wrote:

https://parts.arrow.com/item/detail/arrow-development-tools/bemicrocva9#FR2n

just got a mail to say it has shipped, great news that you are going to use one

On Wednesday, June 3, 2015 at 7:12:17 AM UTC+1, Steve Haynal wrote:

That is great news. I want to use one to protoype and test gigabit ethernet. They aren't listed as in stock yet on the US arrow site. Which site did you find them at?

73,

Steve

KF7O

On Tuesday, June 2, 2015 at 7:38:05 PM UTC-7, Alan Hopper wrote:

I just got an email from arrow saying that my cva9 is about to ship, they are now listed as in stock on the website.

Alan M6NNB 

--
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.

-- 
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

--
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.

[John Laur]

I believe that the CV A9 layout was done by Scotty WA2DFI's company
(Zephyr Engineering http://www.zpci.com/), or at least they may be
intimately familiar with it. You might be able to get the exact
details from him, Steve.

Understood on the Max10 bemicro. I saw the reference to usb 3.0 in the
lab class/tour they are doing this month. I suppose that is in
conjunction with the BeUSB 3.0 add-on board though and is not an
onboard part. Sorry!

The DE0-SoC does look very interesting, but the base part is still
over $150. I have a SoCKit, but the proprietary HSMC connector is not
particularly fun. The top row of headers looks very close to the FPGA
pins so it still might be possible to get adequate bandwidth. I
imagine the Cubicboard is not going to get any cost benefit from being
a developer board, but their module approach is very interesting.

73, John K5IT

[Rick Koch]

Steve, do you think we can get the GigE FPGA code from the HPSDR group, aka Phil/VK6PH?

I ordered one.

Looking at the hardware manual (which doesn't include a schematic)

http://download.siliconexpert.com/pdfs/2014/9/30/1/59/55/972/arrowd_/manual/hardware_reference_guide_bemicro_cv_a9_10.pdf

I'm having a hard time matching the 80 pin connectors routing to the BeMicroCV

http://components-asiapac.arrow.com/file_system/intranet/MAR/ADRE/File/Hardware_Reference_Guide_for_BeMicro_CV_A2_v1.04.pdf

There are ground pins in there (CVA9) that I don't see on the CV, could this be a problem?

From the Yahoo Group 'SDRStick' I found that the CVA9 requires Quartus Web 15.0 which fortunately is available.

[Steve Haynal]

Hi Rick,

I'm holding off on ordering one until we are sure about the 80-pin pinout. I'll post a query to the sdrstick forum as well as to Arrow.

The ethernet RTL we use now is >90% of what is in the Hermes. It should be easy to convert back to Gigabit again. Note that most Hermes users have never used this at gigabit speeds -- just a few units on a test bench. Most people will not need the extra bandwidth.

73,

Steve

KF7O

[John Marvin]

I found a page that has the schematic for the CVA9:

https://parts.arrow.com/reference-design/80092271AA830AEFEBE14BA843994F0D

Look at the bottom under "Associated Documents".  The BOM for the CVa9 is also located there.

73,

John
AC0ZG

[Steve Haynal]

Thanks! That is just what I was looking for. A quick glance shows that they have connected a few more pins that were originally NC. I will take a closer look this week.

73,

Steve

KF7O

[John Marvin]

It looks like the clocking is different, but I'm not an expert here. On the CV EG_P51 ( Pin 46 on the connector) is CLK2P, on the CVA9 EG_P51 is CLK3N. On the CV CLK2N is connected to Pin 42 on the connector, which on the Hermes Lit goes to "TP4", but I have no idea what "TP4" means.

On the CVA9 CLK3P is connected to Pin 5 on the connector.

Anyway, I'm thinking there might be a way to get it to work, possibly by  placing a 0 ohm resistor on J3 (connecting  CLKOUT1 of the AD9866 to CLK3P on the FPGA) and jumping a wire from one of the pads for J4 on the Hermes Lite (to properly terminate CLK3N from the FPGA), but I'm out of my depth here without a lot more research.

73,

John

--

[Alan Hopper]

My CV-A9 was delivered this morning and I have managed to get the leds flashing, so I can confirm that free version of Quartus 15 does support it.  

It is a little wider and longer than the cv which I had not realized from the pictures but does have useful mounting holes.

Alan M6NNB

[Steve Haynal]

Hi Alan,

That is good to hear. By the way, I have fixed the recent bug you reported. I will share details hopefully this evening when I post updated firmware.

73,

Steve

KF7O

[Paul Phillips]

Hi Alan,

Congrats on getting hold of your CV-A9.  Did you have to pay a lot for shipping to the UK?  I looked at ordering a BeMicro CV from Arrow USA a couple of weeks ago but they wanted something like USD 45 for shipping.  So I asked Arrow UK and if you have an account with them they can supply the BeMicro CV for about £24.50 plus about £12 delivery.  However, they can't give me a price for the CV-A9.

73,

Paul G4KZY

[f1v...@orange.fr]

Hi Paul.

I had the same experience as you in acquiring  the BeMicro CV in the end I ordered from the USA.

But had it delivered to a friend in California who is coming to his holiday home here in France in a couple of weeks.

I also asked about the CV-A9 but was told the 80pin edge connector is not compatible with anything that plugs on to the SDK or CV

.

As other people on here have stated so decided to give the CV-A9 a miss.

73 Peter F1VKK

[Alan Hopper]

Paul, yep the shipping was about $44 and I got a £20 customs bill, however Arrow misquoted me $49 for the a9 so I didn't really mind!

Alan

[Alan Hopper]

I just had a play at porting the code to the cva9. I have no fpga experience other than flashing leds so what follows was a total shot in the dark.  Any pointers to the correct way of doing this gratefully received.

I figured the easiest way to start was to use the a9 with the waveshare board, this way it is just a big cvc8.

Using quartus 15 I created a new revision based on the cvc8 and changed the device to the correct a9.

I edited the pin assignments, I think it was just the leds that changed.

Compiling seemed to  stall on 'Using advanced physical optimisation' so I turned that off, it then compiled.

To my utter amazement it installed and runs. 

I ran it in test mode with no radio, my software finds it on the network, it responds to start and stop commands and sends back blank bandscope data however no receiver data is sent back.

The leds don't behave like test mode normally does 1,2,3,4 & 8 are on all the time 5&7 flash on start & stop and 6 is on when started.  This is way more progress than I expected.

I suspect I have now run out of beginners luck so if anyone has any suggestions I'm all ears.

Alan M6NNB

[Steve Haynal]

Using the waveshare sounds like a very good first step. Send me your .qsf file and I will double check your pin assignments.

73,

Steve

KF7O

[John Marvin]

Alan,

I've been looking at the CVA9 differences also. Here is what I got for the Led pin assignment changes:

leds[0], PIN_C21
leds[1], PIN_D19
leds[2], PIN_C20
leds[3], PIN_B21
leds[4], PIN_E21
leds[5], PIN_B17
leds[6], PIN_E19
leds[7], PIN_D21

Is that what you got?

Using the Waveshare isn't an option for me, since I have a BeMicro SDK. At first I thought I'd need new RTL for a whole new Phy, before I realized that the Phy on the CV-A9 is the same Phy that is on the Hermes board. So perhaps that makes it possible for me to do. I'll be trying to merge the Hermes
Phy code with the Hermes-Lite code.

I'm still concerned about the polarity difference on the ADC9866 clock connection, but I could very well be wrong about that. But the first step is
getting things working in test mode  with the built in Phy.

73,

John
AC0ZG

--

[Alan Hopper]

Steve, John,

here is my qsf file so far.

Alan M6NNB

[John Marvin]

OK, it's probably an easy task for Steve to merge the Hermes phy code, but I've forgotten too much. I decided a WaveShare board is pretty cheap, especially with Amazon Prime shipping. :)

John

On 6/10/2015 12:33 AM, John Marvin wrote:

[Alan Hopper]

In another lucky shot in the dark, I inverted the references to exp_present in hermes_lite_cv.v and it all started working perfectly in test mode.  I've double checked the exp_present pin allocation and it seems ok, could it be floating high or have a pullup enabled?

Alan M6NNB

[John Laur]

Steve,

Did you ever get the gigabit code from Joe or Phil? They are using it
in both the new protocol test and the DFC with Angelia. I think the
PHY is the same as CVA9.

Alan,

Awesome to know it basically works on CVA9. We should be able to fit
all 8 Rx on there plus the PS receiver. I was on the fence about
building up a 1.22 board before the next rev but it looks like it may
remain very useful to have one to work with the CVA9 board. If they
release a bemicro with a SoC on it we may have even more experiments
to try.

73, John K5IT

[Alan Hopper]

Just looking at making it work with the real radio.  I think I need to route AD9866clk to PIN_W16 this means using jumper 3 instead of jumper 4, does this sound right and can I leave j4 connected so I can switch between cv and cva9 ?

Alan M6NNB

[John Laur]

Ah ok I jumped the gun; I see that the test mode is working.

Hopefully the 1.21/22 boards will work on new board with the current
pin assignments.

I am quite sure that Scotty would have been somewhat sensitive to this
when he did layout as I know they wanted their SDRStick hardware to
work with the CVA9. But Hermes-Lite may use different pins...

73, John K5IT

[Rick Koch]

I know it's been discussed here several times that for general Ham HF spectrum monitoring
one really doesn't need 8 rcvrs with 192Khz and I agree.

But my main interest is using the HL for CW & RTTY skimming which requires the 192Khz
bandwidth, and having 8 bands for the HF spectrum covers a lot. Maybe more for VHF and beyond.

For this to happen we'll need the gigabit FPGA code at least on the CVA9.

Besides, I think it's really cool seeing eight 192Khz bandscopes at the same time. :^)

-Rick / N1GP

[Steve Haynal]

Hi Alan,

You are making great progress! I had a chance to look at the CVA9 schematic and I noticed the same 3 difference that you saw:

• The clock pin that jumper 4 uses in the negative half of a differential clock input. The AD9866 provides a single ended clock and the Cyclone V specifications do not allow the negative pin to be used as a single ended clock input. Fortunately, J3 connects to a positive half of a differential clock input so you can use that with the CVA9. Edit the AD9866clk line in the .qsf file to use pin W16: set_location_assignment PIN_W16 -to AD9866clk. You can try having both J3 and J4 shorted. It just means more clock fanout. If you notice signal integrity issues (general flakiness) then remove J4.
• Besides the clock, only the LEDs must be remapped. All other pin assignments can remain the same.
• set_location_assignment PIN_D21 -to leds[7]
• set_location_assignment PIN_D19 -to leds[6]
• set_location_assignment PIN_C21 -to leds[5]
• set_location_assignment PIN_C20 -to leds[4]
• set_location_assignment PIN_B21 -to leds[3]
• set_location_assignment PIN_E21 -to leds[2]
• set_location_assignment PIN_E19 -to leds[1]
• set_location_assignment PIN_B17 -to leds[0]
• The SDK and CV include a pulldown resistor on  exp_present. For some reason, there is no pulldown resistor on the CVA9. Altera allows you to configure an internal pullup resistor, but not pulldown. When this signal is high, the hermes-lite is present and the synthetic clock is disabled. When it is low, the synthetic clock is enabled. If you invert it, it will not work when a hermes-lite is connected. Instead, I would connect this to dip[2] (the extra dip switch) until we figure out something better. You can switch manually.

This is good enough progress that I am going to order my CVA9.

73,

Steve

KF7O

[Steve Haynal]

Hi John,

The Hermes RTL already appears to support gigabit although it is not enabled. I assumed that was the code Phil was using and had tested on the bench in the past. I did look at the code for Angelia a month or so ago and the MAC RTL was the same. I think it will be good enough but where is the repository for the newer code?

The Hermes and CVA9 PHYs are the same.

73,

Steve

KF7O

[John Laur]

Steve,

Ah OK; I do not know if it was ever published in the TAPR SVN yet. You
should definitely check with either Phil VK6PH or Joe K5SO and get
them to send you a .qar of whatever they say is the latest and
greatest version of the gigabit MAC. I could be wrong but I do not
think it is the same code that is used in the release version. I seem
to remember that they had said it was simpler and used less logic than
the 100mbit. I never had a copy.

I think on the teamspeak session last friday there was talk about the
CVA9 and there was talk of some trouble when testing with large
numbers of receivers (more than 8) where timing problems were causing
some to fail. It might have been Phil. If he already has that code
running on CVA9 that might save even more time. I was not listening
that closely so those discussions may have been unrelated.

73 John K5IT

[Alan Hopper]

Thanks Steve,

It works, I have listened to the radio on a cva9!

In the end I did remove j4 but don't believe I had to.

Just compiling lots of receivers.

Alan M6NNB

[Alan Hopper]

Hi List,

I now have 5 receivers working on my cva9, my software happily displays all of them and decodes wspr from them all. The firmware currently only allows for 5 receivers whilst the protocol allows 8, I might have a go at getting 8 working this evening.

I have a problem with programming a jic file, I followed the instructions on the wiki, selected EPCQ256 as the configuration device, active serial x4 as the mode and 5cefa9 as the device. It worked once but now after programming I still seem to have the original file I flashed. 

Alan N6NNB

[Alan Hopper]

My fault with the jic, at some point the location of the file changed and I was uploading the old one! So it all seems to be working, I'll leave it wspr-ing this afternoon.

Alan M6NNB

[Rick Koch]

Alan, congrats on the cva9 progress!

I should have my cva9 later today, I'd love to give your code a try.

Tnx,

Rick / N1GP

[Alan Hopper]

Rick,

Here are the .jic files and the .qsf file which is the only real change.  I have not tested the slower version as I can't.  These files don't have Steve's latest mod in.

The fact that this was so easy to get going on the A9 is a credit to Steve's work. Here is a summary of my A9 findings:-

You need Quartus 15 to compile and the 'Advanced Physical Optimization' in the fitter seems to break it.

This code is based on the CVC8 revision as the a9 is C8 spec.

Jumper J4 is needed on the Hermes Lite, you may be able to leave J3 on, I'm not sure about the other jumper that is needed for the sdk ( I don't have it on).

To use test mode turn dip switch 4 on.

To generate .jic files use 'EPCQ256' as the configuration device, 'Active serial x4' as the mode and '5CEFA9' as the device.

This version need the waveshare board connected just as on a cv, this is a complete bodge but at least proves the a9 and hl  can work together.

The maximum number of receivers that can currently be set in Hermes_Lite_CV.v is 5.

Alan M6NNB

[Steve Haynal]

I just updated git with a verilog wrapper and revision for the CVA9. I think I made all the changes necessary to enable 8 receivers. I updated the firmware too. This assumes 73.728 MHz oscillator, Waveshare ethernet, J3 connected, and dipswitch 2 changing between test and normal modes. Please let me know if 8 receivers work. Try 7,6 and 5 also. I have no way to test this yet, but Arrow said they have shipped my board.

This FPGA has an impressive amount of resources. Only 7% memory, 15% logic and 39% DSP resources were used in the 8 receiver version! The complete Quartus run took 17 minutes 42 seconds even with physical optimization, but I do have the advantage of compiling on my work machine which is a 16 Xeon true processor (not hyper threading) blade server with 132 GB of memory...   

73,

Steve

KF7O

[Alan Hopper]

Steve,

great to see you supporting the A9 (I didn't think you would be able to resist). I just tried your .jic and got no network connection to it, this is what I saw when using 'advanced physical optimization'. I just recompiled with that option off and it works, I have 8 receivers running, brilliant, thank you very much.

My hl has a linear regulator from the 5v to 3.3 and draws it's 5v from the cv, this seems to work fine with the cva9, I ran for about 18hrs with 5 rxs yesterday with no problems.

I will try upping the bandscope width to improve the zooming in my software.

73 Alan M6NNB

[Steve Haynal]

Hi Alan,

Congratulations on getting 8 receivers going! I'm not sure of what software besides yours can actually handle 8 receivers... I'm curious about your setup:

• What is the maximum bandwidth per receiver you can use and still fit 8 in 100 Mb/s? I guess 192 kHz is doable but not 384 kHz.
• How much CPU load are you seeing with 8 receivers and on what processor/system?
• What bands are you spotting on and what antenna system are you using for decent performance across those 8 bands?

I think the next step is to get the onboard ethernet working first at 100 Mbs and then 1000 Mbs. If you are looking into this, it would be nice to do this in a parameterized and cleanly partitioned way so that the single code base supports all platforms. Right now CV,SDK and CVA9 specific RTL is in the wrappers Hermes_Lite_*.v. This will be a little more challenging as the CV and SDK used the same DP83848 although with MII and RMII interfaces, but the CVA9 uses an entirely different PHY.

73,

Steve

KF7O

[Alan Hopper]

Steve,

Once it was working I had to go and earn a living so I left it running wspr on 80,40,30,20,17,15,12 & 10m this is still not enough receivers as I had to leave a couple out! It has run with no problems for at least 10hrs. With 8x 48Khz I see 18% cpu on a fairly old 4 real core I5, a good chunk of this is spent on display which I think can be improved.  The antenna is a vertical dipole for 20m so it is rubbish for most bands.  I shall play with higher bandwidths over the weekend to find the limits.  I would love to have the on board ethernet working for many reasons:- smaller box, lower noise and loads more receivers.  I have a real interest in learning about the fpga stuff and have some uses for it in the day job so am happy to try stuff but will be very much slower than someone with your skills.  I am still very interested in trying to get a similar number of receivers working with a lower powered fpga and suspect my skills are better employed on the pc end.

I wrote my software with the expectation of loads of receivers and radios, now I actually have loads of receivers in front of me I think the user interface needs some tweaks. Once I have the j16 stuff going I shall try to improve the screen usage with many receivers.  I think I'll combine all the wspr reports into one list and add some sort of band vs band comparison. Still need a name for the software.

73 Alan M6NNB

[John Williams]

Is there a way to have a vfo line on the waterfall?

John W9JSW

[Alan Hopper]

John,

yes the waterfall is rather basic at the moment, I'll add a vfo line and at some point all the normal filter overlay.  My grand plan for the display is to be able to tune to a station and then be able to pan and zoom across the whole spectrum of all connected radios with no concern for bandwidth or radio/receiver, to do this really well needs new protocols & firmware.  John L identified a number of real issues with current protocols in a recent post, I also would like the waterfall to pan with everything else.  As I don't have any amplifier on my hl I have not been able to test my voice ssb transmission code with real contacts, any feedback on this would be great.  Building one of your amps is my next hardware task.

73

Alan M6NNB

[John Marvin]

Alan,

I have seriously considered writing a new sdr program, and it looks like you are on the same page as what I wanted to do (although I think you should have used Qt instead, so it would easily port to Macs and Linux).

The one idea that I really wanted to do, and what it appears you want to do also, is to not have the waterfall tear and/or lose history just because you change frequency. The bandscope information should always be kept at highest resolution internally, across the entire chosen sampling rate. If the center frequency is changed that should just start adding new width (and stop at the other end), but not lose what already had been gathered. You can zoom in or out on the internal data and not restart everything. Also, the data should be kept for a longer (user specified) period. It's just memory after all :). There should be the ability to vertical scroll also, i.e. to examine older data. The advantage of all this (just one example) is that you can be zoomed in during a QSO looking in more detail, but when the QSO is over you could zoom out and look for other past activity, which may be intermittent (i.e. someone is calling CQ, but actually being polite enough to pause for 5-10 seconds between calls).

Now a cool related feature, which I also wanted to do, was to also preserve the original I/Q data across the spectrum for perhaps the last few minutes in a queue (again, user specified time). It would be really cool to be able to zoom out, scroll to an area that looked like someone calling CQ (or anything else of interest) and be able to actually put my cursor on the transmission (first set vfo on the desired center frequency and then choose vertical playback location with the cursor) that occurred and "play it back". This of course would also work for the current QSO, but I think it can be done better than the current PowerSDR recording feature (as an example).

I "somehow" got involved in rewriting NetLogger (www.netlogger.org) from scratch. The original author abandoned it at version 2.4 more than six years ago, and it was too old to resurrect in its old form, plus I wanted to do it in Qt. So most of my software development time is going to that effort right now.

So, if you do it right, you'll save me a lot of future effort :).

73,

John

[John Laur]

Tracking the waterfall during tunes is not very easy at the moment.
The reason is that the HPSDR protocol does not tell you when new
samples start coming from the new frequency. There is a "VNA Mode"
hack that does this, but until the new protocol I do not think there
is a way to do this with normal operation. If you just assume that all
data coming from the receiver is on the new frequency immediately, the
waterfall will have discontinuities. There may be some other method to
determine when the change occurs, but I am thinking that it really
needs to wait unil the new protocol version arrives which I think does
this. Alan would probably know better than I would about that.

The same problem exists for keeping IQ in a circular buffer. This is
the reason I ported PowerSDR to compile as 64bit - to hold the
multi-gigabyte buffer. But the frequency shifting FIR that does the
intiial tuning will have to change in frequency at the right moments
as it plays though the IQ history, so again knowing the exact point in
the receiver stream when tunes take place is again necessary.

73, John K5IT

[John Marvin]

Yes, and for it to work seemlessly the frequency changes would have to
be done at packet boundaries. And that would have to take into account
the whole fpga dsp pipeline to do it right. It would also probably be
better to report the center frequency in each packet, rather than just a
marker. That would allow you to just change the frequency without having
to worry about the possibility of sending multiple changes within one
receive packet time.
73,

John
AC0ZG

[John Laur]

Ok I talked to Phil about it tonight. Short answer is there will be a way to do it. By switching a receiver to/from synchronous mode in the new protocol it resets the 2KB FIFO on the internal filters and changes the rx parameters at the packet boundary. PureSignal also has a similar requirement. There is a new high speed command and control protocol too where the rx frequency and packet sequence number could be reported out of band so this may also be a possibility. But the need is recognized.

73, John K5IT

[Steve Haynal]

Hi Alan,

My CVA9 arrived today so I gave it a go with your software. I only get 7 good receivers. The 8th one shows garbage. I tune them all to WWV and compare. Are you getting a good 8th receiver? I am wondering if it is a logic error or timing issue in the RTL. Since we are running at 73.728 MHz, we have an easier job of meeting timing than a Hermes at 122.880 so suspect I messed up on some of the settings for the 8th receiver.

It looks like there are a few bits free in the C0 protocol byte to select the receiver. Shall we extend it and go for 16 receivers? 

73,

Steve

KF7O

 

On Friday, June 12, 2015 at 9:52:16 AM UTC-7, Alan Hopper wrote:

Steve,

[Alan Hopper]

Steve,

Now I look harder I also only seem to get noise on receiver 8, looking at the protocol document there does not seem to be a way to set the frequency for receiver 8 so I guess it is running fine at whatever frequency it starts up at. It would explain why I got no 10m wspr decodes!  I'm certainly up for going for 16 receivers, I'll only have to tweak the protocol stuff, the rest of the code can handle any number of receivers and is only limited by processing power.  I'll look harder at the protocol document just in case I have missed something.

73

Alan M6NNB

[John Marvin]

I just started testing, and when changing some test code from 7 receivers to 8 receivers I noticed there was no command for setting the NCO for the 8th receiver. So I don't think you are missing anything. In fact,
there may be an issue if and user code tries to set a frequency for the 8th receiver by just indexing the proper command code based on the command for the 1st receiver, because then you'd be overwriting the command that sets the drive level (and a bunch of Alex configuration).

Steve, if you are going to add more receivers, you need to also add commands for setting the NCO for each receiver. That last current command in the current protocol is 0x22 for setting the CW PWM envelope. Even though that isn't implemented on Hermes Lite, it probably makes sense not to collide with existing commands. Currently the NCO commands for Receivers 1-7 are: 0x04, 0x06, 0x08, 0x0a, 0x0c, 0x0e, and 0x10 (the
least significant bit is the MOX bit). I would suggest starting at 0x24 for receiver 8 NCO, e.g. receivers 8-16 would have the following C0 values: 0x24, 0x26, 0x28, 0x2a, 0x2c, 0x2e, 0x30, 0x32 and 0x34.

I'd love to see this implemented.

73,

John
AC0ZG

[John Marvin]

Steve,

Just out of curiosity, did you have to disable "Advanced Physical
Optimization" to get it to work? Alan had to do that, but I didn't have
to do that on my CV A9. The only difference I know of between his setup
and my setup is that I'm still using the lower frequency crystal on my
Hermes Lite, since I haven't ordered the 73.728 Mhz crystal yet.

Also, I'm fine with whatever number of receivers you want to implement,
but the new protocol currently has a limit of 15 receivers, so perhaps
that might be a good number to go with, unless we're trying to find just
how many we can get to work!

73,

John

[Steve Haynal]

Hi Alan and John,

I updated the RTL to use C0 of 0b0010_010x for RX8 frequency as John suggested. It had been 0b0001_001x and was colliding with some Alex and other settings. 

John - Where do you see 0x22 for CW PWM envelope? In the document I'm looking at, the last used is 0b0010_000x (0x20). Is there a newer document than v1.57?

We will also need to extend the number of receivers encoded in bits [5:3[ of C4 when C1 is 0b0000_000x which currently imits us to 8. I propose just using bits [7:3] for max 32 receivers. Although it does step on a mic timestamp bit [6] and a Mercury bit [7], these are not used in the Hermes RTL and it would make things simpler if the max receiver data all came at the same time. Any objections?

Regarding the new protocol, the little of it that I've heard about sounds interesting. I have no desire to be an early adopter though. Once it is established a bit and the dust settles down, we can probably switch to it.

I need to spend a few hours working on the full-duplex tests and fulfilling Tindie orders, so probably won't get back to this until later in the week. I do want to try and max out the CVA9 on receivers though. There may be some UDP packet size we start encroaching on.

73,

Steve

KF7O

[Steve Haynal]

I haven't tried again with the Advanced Physical Optimization on. I didn't event try my first .jic after Alan told me it didn't work. I'll have to try again. There may be a difference in Quartus 15.0. I am using build 145. I noticed that a few of the old waveshare timing paths are popping up again so that may be the issue.

73,

Steve

KF7O

On Sunday, June 14, 2015 at 1:29:35 AM UTC-7, John Marvin wrote:

[John Marvin]

Looking at the RTL, it looked fairly easy to add more receivers, so I tried it by increasing NR to 16 and making the appropriate changes to support that. It compiled, but it didn't close timing. But it seems to work! Actually, I've only tested 12 receivers out of the 16 available, since my test program only tests the allocated standard WSPR bands (including experimental ones like 2190m and 560m), and there are only 12 of those from 2190m to 10m.

Don't know how stable it is, but I've attached my changes in case anyone else wants to play (You still need to set NR to 16 in Hermes_Lite_CVA9.v also). The commands for setting the NCO for receivers 8-16 are as I proposed below.

73,

John
AC0ZG

[John Marvin]

On 6/14/2015 12:09 PM, Steve Haynal wrote:

Hi Alan and John,

John - Where do you see 0x22 for CW PWM envelope? In the document I'm looking at, the last used is 0b0010_000x (0x20). Is there a newer document than v1.57?

Yes, the latest protocol document version is v1.58, located here:

http://svn.tapr.org/filedetails.php?repname=OpenHPSDR+Main&path=%2Ftrunk%2FDocumentation%2FUSB_protocol_V1.58.doc

We will also need to extend the number of receivers encoded in bits [5:3[ of C4 when C1 is 0b0000_000x which currently imits us to 8. I propose just using bits [7:3] for max 32 receivers. Although it does step on a mic timestamp bit [6] and a Mercury bit [7], these are not used in the Hermes RTL and it would make things simpler if the max receiver data all came at the same time. Any objections?

No, in fact I already did the same thing, except currently only for 16 receivers using bits [6:3].

73,

John
AC0ZG

[Steve Haynal]

Hi John,

Thanks for the pointers and congratulations on 12 receivers! If you have a fork, you can issue a pull request and I will pull your changes into the main branch. The only other changes I'd like to see is to use the 7th bit so we can go up to 32 receivers, and to change the unrolled loop in hermes_lite_core.v to use a parameterized generate statement so some stuff is not built if NR is a low number. (I know, I didn't use a parameter here too yet.)

73,

Steve

KF7O

[John Marvin]

Steve,

I currently don't have a git fork, but I can look at doing that. My main concern is that support for 16 receivers does not close timing, although it appears to work. I probably wouldn't be able to figure out how to fix things to close the timing problems.

As far as maximums go, we won't run into any issue with UDP packet size, since the sample packet size is constant. The current protocol uses a 1032 byte packet for receiver/mike samples, consisting of a 8 byte header, and two 512 byte encapsulations of the USB protocol. The protocol just packs less samples per 512 byte "USB" packet as the number of receivers is increased. As far as that issue goes, we can go up to 83 receivers, at which point there would be only one sample per receiver in each 512 byte "USB" packet.

However, when we get to 32 receivers we'd be approaching (possibly exceeding, since we can't really get 100% of the physical layer bandwidth) the maximum bandwidth for the Waveshare lan card at the minimum receiver sampling rate (48Khz). To go beyond that we'd need to support a lower sampling rate (e.g. 24 Khz, probably not worth the effort), or get the 1Gbit support working for the CVA9 on board phy.

I know there are some people who want lots of receivers in order to be able to host shared receiver slices over the web, but I'm pretty happy with 12-16. Of course, I really want 12-16 at a higher sampling rate than 48 Khz in order to skim at least the CW and digital portions of every ham band.

73,

John
AC0ZG

[Alan Hopper]

Steve,

I see no problem with this, unless any of the existing clients set the timestamp or mercury bits, easy to see by connecting to patroclus as it now shows all set cc bits.  Should be a few minutes work to support in my software. Currently I correctly don't send rx8 frequency.  If you stick to the current encoding the udp packet size should not increase, you just get fewer samples per packet, with 32 receivers there should be int( 512/(32*6+2)) *2 iq samples per packet which is only 4 with padding(off the top of my head), the packets will be coming at quite a rate:).  I shall try adding the extra receiver stuff to the emulator.

73

Alan M6NNB

[Rick Koch]

I added the capability for up to 16 RCVRs in cudaSDR. I haven't tested it yet as I don't have a DP83848
for my CVA9. Let me know if it works for you...

https://github.com/n1gp/cudaSDR

[Alan Hopper]

Rich

I have just uploaded new source to my emulator that should emulate 32 receivers https://github.com/ahopper/Patroclus so you could test with that.  I have a version of my software working with the emulator, will test with Johns firmware next.

Alan

[Alan Hopper]

John,

brilliant, it worked first time for me, 16 receivers all working properly.

73 Alan M6NNB 

[John Laur]

The "old" (current) HPSDR protocol is extremely unlikely to change
again; I do not think there is a problem extended it with whatever
additional C&C bytes you might want for the additional receivers.

The new protocol obviously includes support for defining any number of
receivers and transmitters. I know Phil mentioned some trouble in
getting timing closure using a large number of receivers on his new
code. There may be some commonality with the problem that you all are
experiencing moving up from 8 rx.

Until such time as the new protocol is published and ready to be
ported for Hermes-Lite I am sure that Phil would be happy to have an
update to the current protocol doc with the hermes-lite extensions.

Another advantage of the BeMicro CVA9 that I am looking forward to is
MOUNTING HOLES!

73, John K5IT

[Rick Koch]

I took a stab at getting the on-board Ethernet port working, at least in 100T mode.
I think I have all the right pin defs Hermes_Lite_12CVA9.qsf and changes to Hermes_Lite_CVA9.v
(attached), but it's not coming up.

Any ideas?

[John Marvin]

Rick,

I looked at doing this (I haven't yet looked at your changes), but the area that I got bogged down on was the clock definitions. Since you didn't supply a modified Hermes_Lite_CVA9.sdc I suspect that you didn't look at making the appropriate clock changes. Of course I could be totally off base, since my knowledge regarding RTL is just enough to be dangerous most of the time and get it right only some of the time.

73,

John
AC0ZG

[Steve Haynal]

Hi Rick, John and Alan,

This is great to see some interest in helping with the RTL! I bought my CVA9 primarily to get gigabit ethernet working as I want to use an almost identical chip in v2.0, so eventually it will happen but do appreciate any help I can get. Here is what I can think of off the top of my head regarding what will need to be changed:

• Model it after the existing SDK interface which is MII, not RMII. The RMII to MII converter in the CV code is not needed.
• Update pin assignments in .qsf
• Update pin names/direction in verilog. The different PHY may require/supply different clocks.
• Update the .sdc with the new clock constraints, frequencies and IO constraints.
• The configuration done in MDIO.v is quite different between the two PHYs. You'll have to update this configuration as well as what bits are used for sensing certain conditions.
• For 100 Mb/s we are essentially reverting back to the Hermes MAC. You can use the Hermes RTL as a reference. Unfortunately the Hermes-Lite has really forked so it may be difficult to merge back.

73,

Steve

KF7O

[John Marvin]

Hi Steve,

That reminds me, I'd like to make an appeal to consider some
alternatives to putting an FPGA on the main Hermes-Lite board. I know
keeping the price down is a primary objective, but the modular
capability of the various FPGA development boards allows for a lot of
flexibility, including cheaper and more powerful FPGA's in the future.

Here are two alternatives I'd like you to consider:

1) Leave the Hermes-Lite board similar to what it currently is, with
only minor improvements to make sure it is as compatible with a variety
of planned features for various front-end boards, and the different
possible FPGA development boards (i.e. the current and near future BE
fpga boards). In order to allow for a lower price point, develop a
separate economy fpga board that has only what you had planned to put on
the main board, but which has the 80 pin edge connector. This scenario
allows for flexibility at the additional cost of the separate pcb and an
80 pin edge connector. It also makes the development process easier,
i.e. you can concentrate on getting the low end fpga board right and not
have to keep building new boards with all the Hermes-Lite hardware at
the same time.

2) Develop two versions of the Hermes-Lite board, one with the fpga and
one without. However, to keep things as similar as possible, layout the
board with the fpga as if it was a separate board, i.e. the fpga,
ethernet phy and supporting chips would be on one side and traces would
be routed as if they were going to an 80 pin edge connector, but they
would just cross to the other side where the rest of the Hermes-Lite
hardware was placed. This would reduce the probability of hardware
differences that might lead to problems and differences between the two
solutions.

I think you can already see that some people are quite excited about the
possibilities that the CVA9 offers, and it also looks like Arrow plans
to keep making low end fpga development boards with the 80 pin edge
connector. Having the edge connector option allows someone to start out
with an economy fpga board (e.g. either one you develop that has none of
the frills, or something like the BE-SDK), and then upgrade at a later
date to get some additional features they would like to have (and still
not have to get near the range of a Hermes or Apache-Labs board).

73,

John
AC0ZG

[John Marvin]

Steve,

I couldn't get a generate/for loop setup that Quartus would accept. My understanding is that the generate has to be at the outer layer. I tried reordering some of the associated code to live within the generate for loop, but that didn't work either. So I'm going to have to let you do that if it is possible. Another option would be to move the code into a separate file and have a version for the CVA9 and one for the other boards, but getting the generate to work would certainly be a more elegant solution.

Note that my attempt left the setup of the first 7 receivers as they were, i.e. I only added the generate for receivers 8-32.

73,

John
AC0ZG

[Alan Hopper]

Steve, All,

I've now run John's firmware for over 24hrs listening to wspr on 12 channels with another channel to listen to the bbc. It has worked flawlessly, I have spotted wsprs on all frequencies except lf 136kHz. It must be my biggest 24hr spot count by far. I now need an antenna to do the radio justice.  I'm delighted with this as it was my target when I first saw this project. So a big thanks to everyone involved.

On the rtl front, to avoid duplication of effort, I think I might have a go at removing the firs and doing that part on the pc.  Hopefully my skills will improve so I can be of more help.

73

Alan M6NNB

[John Marvin]

Alan,

Just out of curiosity, but what is the benefit of moving the fir
processing to the PC? I can see that in the "fat pipe" scenario, but
that is a whole other ballgame. Are you trying to get the resource usage
down so that there can be more receivers on a smaller fpga?

73,

John

[Alan Hopper]

John,

yes the idea is to get more receivers from smaller fpgas, there is a trade off as more bandwidth will be used per receiver.

73

Alan M6NNB

[Rick Koch]

I'm not sure what to do about PHY_CLK125

The CVA9 uses a KSZ9021RN -vs- KSZ9021RL which looks like just a package difference.

However looking at the CVA9 schematic it there appears a difference with how PHY_CLK125

connects to the Phy.

CVA9:

Pin 41 (CLK125_NDO/LED_MODE) isn't attached to PHY_CLK125

Hermes_Lite_12CVA9.qsf only has:

set_instance_assignment -name GLOBAL_SIGNAL "GLOBAL CLOCK" -to PHY_CLK125

Hermes:

Pin 55 (CLK125_NDO/LED_MODE) is attached to PHY_CLK125

Hermes.qsf has two PHY_CLK125 references, one to an actual pin:

set_instance_assignment -name GLOBAL_SIGNAL "GLOBAL CLOCK" -to PHY_CLK125

set_location_assignment PIN_149 -to PHY_CLK125

How to handle this?

[Steve Haynal]

Hi John,

I've noted your appeal! It is too late at night for me to respond in detail, but I eventually want to share a detailed document that addresses these issues for feedback. Your option 2 seems possible with the current Hermes-Lite 1.2 and rev 2.0.

73,

Steve

KF7O

[Steve Haynal]

Okay. I will eventually get around to it, but at least you, Alan and Rich are set now with 16 receivers.

73,

Steve

KF7O

[Steve Haynal]

That is great news. I ran WSPR overnight with 7 receivers and your software and was impressed with the total number of spots.

73,

Steve

KF7O

[Steve Haynal]

Hi Rick,

With RGMII it is your responsibility to generate the TX_CLK output. In the Hermes design, they used the PHY_CLK125 from the KSZ9021 into a PLL to generate the 25 MHz clock for TX_CLK at 100 Mb/s. With the CVA9, since this clock is not connected, you will have to use another reference like the 50 MHz clock and a PLL to generate the 25 MHz for TX_CLK. This differs from the DP83848 PHY used in the WaveShare and SDK where TX_CLK was an input. Timing is more critical at 1 Gb/s where data is transferred on both edges of a 125 MHz clock. This document may be helpful.

73,

Steve

KF7O

[Rick Koch]

OK tnx Steve, I'll check out the document.

But still, won't we need the 125Mhz clock for Gigabit Enet?

[John Marvin]

Rick,

You can generate a 125Mhz clock from the 50 Mhz clock using a PLL just like you would use a PLL to generate a 25 Mhz clock from the 50 Mhz clock. In one case you are doing clock multiplication (which requires a PLL) and the other case you are doing clock division (which doesn't require a PLL for nice multiples, but it's still better and easier to use a PLL).

73,

John
AC0ZG

[John Laur]

All,

I have written to double check the status of the latest code which
supports gigabit on the KSZ9021. I know that for SDK and CV Steve
started with a prior version of the Hermes firmware and did quite a
bit of refactoring to get it going properly with the SDK and WaveShare
boards. I do not believe it is a simple matter of adjusting pin
definitions to get it working again on the CVA9 onboard ethernet.

In any case, it is worthwhile to check that any new porting effort
starts from the latest working version that is closest to the hardware
we have. Since only a couple of people really work on the HPSDR
firmware, we need to check with them. The best starting point may be
code within the still-in-development "new protocol" firmware for the
Apace-Labs Angelia board.

I will report what I learn here.

73, John K5IT

[Steve Haynal]

Thanks for looking into this. It would be helpful to have other code for reference. What we could really use is the MAC sdc timing constraints for the CVA9 when operating at 1 Gb/s. There is no reference design that I could find yet. This is board layout specific so we need something for the BeMicro CVA9. Perhaps someone could ask the sdrstick list for these. We need to know if they are using PHY internal delays too, as described here.

73,

Steve

KF7O

[Steve Haynal]

I received this e-mail from Phil this morning. I haven't spent much time on gigabit yet but this should be helpful.

Hi John and Steve,

I've made a public release of the Gigabit new protocol code. It is here:

http://svn.tapr.org/repos_sdr_hpsdr/trunk/Angelia_new_protocol/

Please read the notes in relation to the current release.  See also the block diagrams in the Documents directory which should assist
with understanding how it all hangs together.

Please let me know if you need any additional information.

73 Phil....VK6PH

[John Laur]

All,

I use an Angelia board day to day, and all of Joe K5SO's sources have
been in .qar archives. This release follows the similar archive
format.

In an effort to make the code more accessible, particularly the
development history and the code changes from version to version, I
have (with Joe's permission) been tracking the source releases in a
Github repository. I created a branch to examine the changes in Phil's
initial new protocol June 20 release. Being able to see the diff may
be of some benefit to gigabit or new protocol porting efforts for
Hermes Lite, so I wanted to mention this resource.

Angelia firmware repo (including all history back to v0.1):
https://github.com/johnlaur/Angelia

Comparison of new protocol branch vs most recent "old protocol" release:
https://github.com/johnlaur/Angelia/compare/new_protocol

73, John K5IT

[Joe]

Which BeMicro?

I'm currently using the SDK and would like to keep my radio intact

the 1.22 version is arriving soon and I need to order another FPGA

which of the products should I order for future growth?

SDK used now has mounting holes

 

CV a little cheaper- has anyone figured out how to mount it?

CVA9 most expensive has mounting holes what about future code?

Tnx  Joe    wa9cgz

 

[f1v...@orange.fr]

Hi Joe.

Found this on the group.

http://tinyurl.com/o42wren

Hope this helps.

73 Peter F1VKK

[Steve Haynal]

Hi Joe,

You may be able to find plastic standoffs that clip on to the CV from the side too.

The CV is a little cheaper even after the price of the waveshare ethernet. How the waveshare connects to the CV is a bit unwieldy. The CVs have LVDS which is what I eventually want to use to synchronize two receivers to make them coherent. The CVs have the additional 40 pin connectors.

The SDK support 3 receivers versus the CVs 2 and has onboard ethernet.

The CVA9 has a massive amount of resources and onboard gigabit ethernet. Several people have 16 receivers running with resources to spare. We are still using the waveshare ethernet. I purchased mine to learn how to use gigabit ethernet for v2.0. Firmware releases will support at least the CVA9 with waveshare and eventually onboard ethernet.

73,

Steve

KF7O

 

[pascal.v...@gmail.com]

Hi,
A few questions to the  CVA 9 users :
- how to supply the CVA 9 ? with the 5V plug ? Can we supply the HL v1.22 from the CVA9 ?
- Is the wiki instructions for the jumpers the same for CVA9 and CV
Thanks

[in3otd]

Hello Pascal,
I use a CV A9 with its 5V wall wart and have connected J7 on the H-L to provide it with the 3.3 V generated by the CV A9 board. Works well, I didn't see any problem so far. I have a small heatsink attached over the FPGA and usually keep a small fan running near the boards to keep them cooler even if it is probably not really necessary, as I have forgotten to turn it on more than once, hi.
You need also jumper J3 to provide the clock to the right pin (or at least this is what I understood looking at the code, did not try if it works without)

I'll try to update the wiki with these info,

73 de Claudio IN3OTD (and ex F5VMW)

[Steve Haynal]

Hi Pascal,

Yes, the 5V wall wart with J7 is sufficient for the CV or CVA9. Only the SDK can't supply enough current to power the HL from the SDK.

J3 is required for the CVA9.

73,

Steve

KF7O

[pascal.v...@gmail.com]

Thanks, that looks easy.
I am ordering for the CVA9 from arrow europe, and wait for the front-end 1.2 pcb at oshpark and the pe4259 from utsource to rebuild a new setup that will be used as an exiter as well as a vna later. Of course the V2 will simplify the task when ready.
I will have a  front-end v1.2 pcb and main components in excess if anyone needs one in Europe.
73