Gateware flashing success

[Jaroslav Škarvada]

Hi,

I finally decided to update gateware on my Hermes Lite 2.0. I used
Quartus Prime Pro Programmer v19.2.0.57 on Linux Fedora 30 x86_64. As a
USB Blaster I used the following clone [1]. It's a bit more expensive
than the cheap STM32 based clones, but for me it worked flawlessly. I
upgraded to gateware version 64, then I used HPSDRProgrammerV2-nopcap to
update through the Ethernet to version 65 - thanks Steve for this :)

Regarding the HPSDRProgrammerV2-nopcap I will package it into Fedora, so
it will be available there out of the box as the distribution package.

One minor problem I have encountered during the flashing through the
Ethernet was that I accidentally flashed HTML preview file from the
github not the raw binary file itself, but I quickly recovered the
device through the JTAG. I will probably create some pull request to
HPSDRProgrammerV2-nopcap upstream adding some sanity check for this

thanks & regards

Jaroslav, OK2JRQ

[1]
https://www.ebay.com/itm/FPGA-CLPD-NIOS-JTAG-Rev-C-Hardware-Altera-USB-Blaster-Download-Cable/163425943598

[Steve Haynal]

Hi Jaroslav,

Thanks for the update and including this in Fedora. That is surprising that HPSDRProgrammerV2-nopcap is not doing any basic file type checks. Unfortunately, I don't think this is under active development. I should probably fork and keep an updated version on the HL2 github, but there is never time. SparkSDR will also now update the firmware. Eventually, I'd like to add the same to Quisk.

73,

Steve

kf7o

[Christopher KB3CS]

i can certainly add a check to ensure the file name ends with ".rbf" .. 

but that not being all that robust, are there some things unique to every raw binary file?

the first four 32 bit words are all 1s?  as in, 4 times 0xffffffff ?

are the last eight 32 bit words special in some way?

  - 0b1001001 -

On Sunday, September 8, 2019 at 6:02:10 PM UTC-4, Steve Haynal wrote:

Hi Jaroslav,

Thanks for the update and including this in Fedora. That is surprising that HPSDRProgrammerV2-nopcap is not doing any basic file type checks. Unfortunately, I don't think this is under active development. I should probably fork and keep an updated version on the HL2 github, but there is never time. SparkSDR will also now update the firmware. Eventually, I'd like to add the same to Quisk.

73,

Steve

kf7o

[...]

[Sid Boyce]

This time i  used the USB-Blaster and Quartus 15.0 to program the Build5
and Build8.
Previously I used HPSDRProgrammer_web on openSUSE and Ubuntu to program 
Hermes with Protocol2 firmware.

I listen to the openHPSDR weekly podcasts -- tsarchive.openhpsdr.org.

Dave (KV0S) who is author of HPSDRProgrammer had said some months ago
that he was working on developing for the Go programming language but
has not had much time to do programming. That was until yesterday's
podcast when he intimated he did a little bit in the last week.
I have not seen an update in github since May 2017.
He has had to take on teaching an additional university class and the
additional work associated with it.

In the general discussion Bill (KD5TFD) asked Phil (VK6PH) if he had
seen the HermesLite2 article on hackaday, Phil promised to have  a look
at it.

Overall nothing much in the way of development is happening as those
guys seem snowed under with their day jobs.
73 ... Sid.

On 08/09/2019 23:02, Steve Haynal wrote:
> Hi Jaroslav,
>
> Thanks for the update and including this in Fedora. That is surprising
> that HPSDRProgrammerV2-nopcap is not doing any basic file type checks.
> Unfortunately, I don't think this is under active development. I
> should probably fork and keep an updated version on the HL2 github,
> but there is never time. SparkSDR will also now update the firmware.
> Eventually, I'd like to add the same to Quisk.
>
> 73,
>
> Steve
> kf7o
>
>
> On Thursday, September 5, 2019 at 11:36:46 PM UTC-7, Jaroslav

> Å karvada wrote:
>
> Hi,
>
> I finally decided to update gateware on my Hermes Lite 2.0. I used
> Quartus Prime Pro Programmer v19.2.0.57 on Linux Fedora 30 x86_64.
> As a
> USB Blaster I used the following clone [1]. It's a bit more expensive
> than the cheap STM32 based clones, but for me it worked flawlessly. I
> upgraded to gateware version 64, then I used
> HPSDRProgrammerV2-nopcap to

> update through the Ethernet to version 65 -  thanks Steve for

> this :)
>
> Regarding the HPSDRProgrammerV2-nopcap I will package it into
> Fedora, so
> it will be available there out of the box as the distribution
> package.
>
> One minor problem I have encountered during the flashing through the
> Ethernet was that I accidentally flashed HTML preview file from the
> github not the raw binary file itself, but I quickly recovered the
> device through the JTAG. I will probably create some pull request to
> HPSDRProgrammerV2-nopcap upstream adding some sanity check for this
>
> thanks & regards
>
> Jaroslav, OK2JRQ
>
> [1]
> https://www.ebay.com/itm/FPGA-CLPD-NIOS-JTAG-Rev-C-Hardware-Altera-USB-Blaster-Download-Cable/163425943598

> <https://www.ebay.com/itm/FPGA-CLPD-NIOS-JTAG-Rev-C-Hardware-Altera-USB-Blaster-Download-Cable/163425943598>
>
>
> --
> 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>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/hermes-lite/1c13966b-b501-4765-8594-f4b10c3b1430%40googlegroups.com
> <https://groups.google.com/d/msgid/hermes-lite/1c13966b-b501-4765-8594-f4b10c3b1430%40googlegroups.com?utm_medium=email&utm_source=footer>.


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

[Jaroslav Škarvada]

NP, I will probably package HPSDRProgrammerV2-nopcap for the start to
have something usable in the Fedora out of the box and I can package any
other SW later as it appears. Feel free to let me know

Jaroslav, OK2JRQ

Sid Boyce napsal(a):

[Christopher KB3CS]

i gather from careful examination of the original svn and the github, May 2017 was when the contents of the svn were committed to the 'new' github.

last commit for HPSDRProgrammer was prior to that date.

  - 58 (base 13) -

On Sunday, September 8, 2019 at 7:19:08 PM UTC-4, Sid Boyce wrote:

[...] 

Dave (KV0S) who is author of HPSDRProgrammer had said some months ago
that he was working on developing for the Go programming language but
has not had much time to do programming. That was until yesterday's
podcast when he intimated he did a little bit in the last week.
I have not seen an update in github since May 2017.
He has had to take on teaching an additional university class and the
additional work associated with it.

[...]

[Christopher KB3CS]

interesting trove .. it seems to indicate a 12 year long hiatus.

  - 58 (base 13) -

On Sunday, September 8, 2019 at 7:19:08 PM UTC-4, Sid Boyce wrote:

[...] 

I listen to the openHPSDR weekly podcasts -- tsarchive.openhpsdr.org.

[...]

[Sid Boyce]

John said he was hoping to update pihpsdr quite a while back but nothing
since, he is working with others on another big project unassociated
with SDR.
linhpsdr has been updated Tue Jun 18 22:19:19 but I get no spectrum or
audio with HL2 though it works with ODYSSEY2 -low signal level -60dBm.
pihpsdr no filter settings seem available but HL2 otherwise works.
73 ... Sid.

On 09/09/2019 15:06, Christopher KB3CS wrote:
> i gather from careful examination of the original svn and the github,
> May 2017 was when the contents of the svn were committed to the 'new'
> github.
> last commit for HPSDRProgrammer was prior to that date.
>

>   - 58 (base 13) -

>
> On Sunday, September 8, 2019 at 7:19:08 PM UTC-4, Sid Boyce wrote:
>

> [...]Â

>
> Dave (KV0S) who is author of HPSDRProgrammer had said some months ago
> that he was working on developing for the Go programming language but
> has not had much time to do programming. That was until yesterday's
> podcast when he intimated he did a little bit in the last week.
> I have not seen an update in github since May 2017.
> He has had to take on teaching an additional university class and the
> additional work associated with it.
>
> [...]
>

> --
> 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>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/hermes-lite/782400d3-12d0-4c5a-a3f0-9f5efd38f451%40googlegroups.com
> <https://groups.google.com/d/msgid/hermes-lite/782400d3-12d0-4c5a-a3f0-9f5efd38f451%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Sid Boyce]

Hermes introduction to availability seemed to take an age so I got
HiQSDR in the meantime.
Forgot pihpsdr OC is where filter settings to be done.
73 ... Sid.

On 09/09/2019 15:09, Christopher KB3CS wrote:
> interesting trove .. it seems to indicate a 12 year long hiatus.
>

>   - 58 (base 13) -

>
> On Sunday, September 8, 2019 at 7:19:08 PM UTC-4, Sid Boyce wrote:
>

> [...]Â

>
> I listen to the openHPSDR weekly podcasts --

> tsarchive.openhpsdr.org <http://tsarchive.openhpsdr.org>.
>
> [...]

>
> --
> 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>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/hermes-lite/30827e4b-d8d2-4142-9451-67057a73a310%40googlegroups.com
> <https://groups.google.com/d/msgid/hermes-lite/30827e4b-d8d2-4142-9451-67057a73a310%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Christopher KB3CS]

i have both spectrum and RX audio from linHPSDR. 

but open a second RX, and then close it, and the UDP stream stops. have to close and restart linHPSDR to continue.

an even faster way to stop the UDP stream is to open the wideband/broadband window. close and restart to continue.

have not even dared to attempt more than 'Tune' for TX.

  - 81 (base 9) -

On Monday, September 9, 2019 at 10:54:15 AM UTC-4, Sid Boyce wrote:

John said he was hoping to update pihpsdr quite a while back but nothing
since, he is working with others on another big project unassociated
with SDR.
linhpsdr has been updated Tue Jun 18 22:19:19 but I get no spectrum or
audio with HL2 though it works with ODYSSEY2 -low signal level -60dBm.
pihpsdr no filter settings seem available but HL2 otherwise works.
73 ... Sid.

[...]

[Jonas Sanamon]

Hi Chistopher,

Have You listened to the resulting TX signal on another receiver when testing "tune"? I think You'll find it is modulated :-)

Cheers,

Jonas

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/52e66318-d3f3-4287-8d14-9a03514fbff7%40googlegroups.com.

[Alan Hopper]

Hi Christopher,

my guess is this is the HL2 watchdog kicking in. I know John had to tweak stuff to make HL2 start once the watchdog was added.

73 Alan M0NNB

[Christopher KB3CS]

watchdog? no, i don't think so. both RXs show spectrum (in my test 40m and 20m). don't recall if i got the audio worked out between the two.

close the second RX and it's equivalent to "all stop".

  - 81 (base 9) -

On Monday, September 9, 2019 at 2:52:38 PM UTC-4, Alan Hopper wrote:

Hi Christopher,

my guess is this is the HL2 watchdog kicking in. I know John had to tweak stuff to make HL2 start once the watchdog was added.

73 Alan M0NNB

[...]

[Alan Hopper]

Hi Christopher,

just a guess on my part, but the watchdog is an obvious cause of the udp stream from the radio stopping, maybe I misunderstood your issue. If anyone wants to try and diagnose it, watching wireshark whilst doing what ever stops it will tell you if the software pauses the udp stream to the radio for long enough for the watchdog to kick in and stop the udp stream from the radio.

73 Alan M0NNB

[Christopher KB3CS]

FWIW, here's the whole packet trace from startup with 1 RX. adding a second RX. then closing the second RX.

then finally closing linHPSDR.

66 MB file stored on Google Drive:  https://drive.google.com/open?id=1KdIscvkc4dVnCGv6GAl-9w62OgeT1MAv

  - 45 (base 17) -

On Monday, September 9, 2019 at 5:04:47 PM UTC-4, Alan Hopper wrote:

Hi Christopher,

just a guess on my part, but the watchdog is an obvious cause of the udp stream from the radio stopping, maybe I misunderstood your issue. If anyone wants to try and diagnose it, watching wireshark whilst doing what ever stops it will tell you if the software pauses the udp stream to the radio for long enough for the watchdog to kick in and stop the udp stream from the radio.

73 Alan M0NNB

On Monday, September 9, 2019 at 9:40:54 PM UTC+1, Christopher KB3CS wrote:

watchdog? no, i don't think so. both RXs show spectrum (in my test 40m and 20m). don't recall if i got the audio worked out between the two.

close the second RX and it's equivalent to "all stop".

  - 81 (base 9) -

[...]

[Christopher KB3CS]

correction.

61 MB file stored on Google Drive: https://drive.google.com/open?id=1ezRg7j6TbG7ObRG2DnqOkzZKOget4HqN

[Steve Haynal]

Hi Chris,

I did take a quick look at the wireshark dump and it is the watchdog timer kicking in. The last packet from host to HL2 was at 178.286 seconds. The HL2 continued to send packets back to the host until 180.992 seconds. Since the HL2 did not see a packet from the host in 2.7 seconds, the watchdog took it out of run. About a year ago the watchdog time was at 0.169 seconds but Alan convinced me it should be longer. I thought 2.7 seconds was more than enough for any software. Should it be longer? What on earth is linHPSDR doing for that long without sending a UDP? This corresponds to the HL2 sending at least 1024 packets (1RX 48kHz but usually more with wider bandwidth/more receivers) without hearing anything from the host. My take is that there is something wrong with linHPSDR which should be fixed as it may have other ill effects.

73,

Steve

kf7o

[Christopher KB3CS]

okay, HL2 watchdog it is! 

i had been working only with my own sensory apparatus, and it seemed the UDP stream stopped promptly upon closing the second RX.

i don't suspect HL2 is doing anything unexpected or unwanted. i think it is operating appropriately.

i also concur. i have suspected the observed behavior is entirely due to linHPSDR. my working theory is linHPSDR has 'forgotten' the first RX should continue operating after closing down the second RX. i don't have a working theory for what happens when you press "Add Wideband", though.

  - 0x49 -

On Monday, September 9, 2019 at 11:38:53 PM UTC-4, Steve Haynal wrote:

Hi Chris,

I did take a quick look at the wireshark dump and it is the watchdog timer kicking in. The last packet from host to HL2 was at 178.286 seconds. The HL2 continued to send packets back to the host until 180.992 seconds. Since the HL2 did not see a packet from the host in 2.7 seconds, the watchdog took it out of run. About a year ago the watchdog time was at 0.169 seconds but Alan convinced me it should be longer. I thought 2.7 seconds was more than enough for any software. Should it be longer? What on earth is linHPSDR doing for that long without sending a UDP? This corresponds to the HL2 sending at least 1024 packets (1RX 48kHz but usually more with wider bandwidth/more receivers) without hearing anything from the host. My take is that there is something wrong with linHPSDR which should be fixed as it may have other ill effects.

73,

Steve

kf7o

On Monday, September 9, 2019 at 2:48:32 PM UTC-7, Christopher KB3CS wrote:

correction.

61 MB file stored on Google Drive: https://drive.google.com/open?id=1ezRg7j6TbG7ObRG2DnqOkzZKOget4HqN
On Monday, September 9, 2019 at 5:31:21 PM UTC-4, Christopher KB3CS wrote:

FWIW, here's the whole packet trace from startup with 1 RX. adding a second RX. then closing the second RX.

then finally closing linHPSDR.

[...]