Gateware 20190907 Released

[Steve Haynal]

Hi Group,

Gateware 20190907 has been released to testing and 20190606 has been moved to stable. 20190907 is the version I am targeting for build9. It will be moved to stable if there are no problems reported over the next week or two. All the details including the change list are on github:

https://github.com/softerhardware/Hermes-Lite2/tree/master/gateware/bitfiles/testing/20190907

73,

Steve

kf7o

[Nigel Head]

Hi Steve,

Updated my HL2b8 and no problems to report here.

I updated over ethernet via SparkSDR.

Nigel - G4ZAL

[Alan Hopper]

Hi Steve,

the tx stuff sounds really good, I'll have a good play with it this week and try and optimise Spark on tx for this.  In other news I took a HL2 to a club open day at polesden lacey where we try to attract new members.  I found a nice feature of the HL2  was the fact that because the whole board is visible and fairly simple you can  point to bits of it like a block diagram and explain it to a 8 yr old.

73 Alan M0NNB 

[Christopher KB3CS]

HL2b8 as received from Makerfabs had "Hermes code" 64 as reported by Quisk (strange, perhaps?)

HL2b8 updated via ethernet using SparkSDR to 20190907 gateware. reported by Quisk as 67.

fetched 20190616 from github. reprogrammed via ethernet using HPSDRProgrammer. reported by Quisk as 66.

reprogrammed 20190907 via ethernet using HPSDRProgrammer. reported by Quisk as 67.

at each "reported by Quisk", the HL2b8 was checked by receiving an over-the-air signal at 7071 kHz.

  - 0x49 -

On Sunday, September 8, 2019 at 11:08:43 AM UTC-4, Nigel Head wrote:

Hi Steve,

Updated my HL2b8 and no problems to report here.

I updated over ethernet via SparkSDR.

Nigel - G4ZAL

[...]

[Steve Haynal]

Hi Chris,

Thanks for the update. I think I mentioned somewhere else that build8 came with 65, but you are right that it was 64. Versions 64 and 65 were actually the same but I released two so that people could test the new ethernet update and see some change.

73,

Steve

kf7o

[Jaroslav Škarvada]

Hi,

I tried to update the gateware from the 20190413 to 20190907 via the
HPSDRProgrammerV2-nopcap and the ethernet update process didn't work for me:

Two left LEDs started blinking and the two right LEDs were on. The
programmer wrote something like "erasing memory, this could take up to
90 seconds" and even after 10 minutes nothing changed. It seemed that
the Hermes Lite 2.0 rebooted itself after some timeout, because after
cca. 5 minutes or so, the left LED started blinking and the right three
LEDs were on and it was normally accessible from the Quisk (but with the
old gateware).

I wasn't brave enough to initiate the update process again, because I am
now on vacation on Pag island (JN74MM, EU-170) and I don't want to brick
the radio and be offline :) (I don't have here the JTAG cable :) Maybe
just my ethernet cable is wrong or there could be some race condition in
the SW - I will retry when I will get back to home, but IMHO this has
probably nothing to do with the 20190907

73! Jaroslav, OK2JRQ

Steve Haynal napsal(a):

> --
> 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/84ff67db-0b5d-4c9c-aec6-4ce5cebb4a0a%40googlegroups.com
> <https://groups.google.com/d/msgid/hermes-lite/84ff67db-0b5d-4c9c-aec6-4ce5cebb4a0a%40googlegroups.com?utm_medium=email&utm_source=footer>.

[rentwist]

Hi Group,

For continuity, I am linking Taka-san's posting about reproducing the AGC issue I reported recently (with Taka-san's gateware) with this latest gateware release.

https://groups.google.com/d/msg/hermes-lite/Sw3oGH_8n4w/EU-ai7OvAAAJ

73,

Robert, WA2T

[dick_...@hotmail.com]

Hi

I also had the same problem today.  I was trying to upgrade from code version 64 [or 6.4 or 20190413 ??] that came on my build 8 board to 20190616 [65 ?].

I was using an existing HPSDRProgrammerV2_nopcap version 2.0.4.9.  There is a newer version 2.0.4.10 on the TAPR page that I also have along with the version that needs the nocap software v2.0.3.0.

Everything was hung up and not responding after it started the "erase".  Closed down and still had code version 64.

I think I will wait until some one can say which versions work.  I do have an untried blaster so I can always get the software and try that.

Dick K9IVB

> an email to herme...@googlegroups.com
> <mailto:hermes-lite+unsub...@googlegroups.com>.

[Christopher KB3CS]

i used version 2.0.4.10. there is a 100/1000 network switch in between the computer and the HL2 (possible there is a 100/1000 network rate wrinkle?).

  - \0111 -

On Monday, September 9, 2019 at 7:56:02 PM UTC-4, dick_...@hotmail.com wrote:

Hi

I also had the same problem today.  I was trying to upgrade from code version 64 [or 6.4 or 20190413 ??] that came on my build 8 board to 20190616 [65 ?].

I was using an existing HPSDRProgrammerV2_nopcap version 2.0.4.9.  There is a newer version 2.0.4.10 on the TAPR page that I also have along with the version that needs the nocap software v2.0.3.0.

Everything was hung up and not responding after it started the "erase".  Closed down and still had code version 64.

I think I will wait until some one can say which versions work.  I do have an untried blaster so I can always get the software and try that.

Dick K9IVB

[...]

[Steve Haynal]

Hi All,

I am using 2.0.4.11 under Linux. I grabbed the source from github several months ago:

 https://github.com/TAPR/OpenHPSDR-Protocol1-Programmers.git

I have not seen this problem. My initial testing included a 100 link in the mix. I have not tried under Windows.

Erase typically takes just a couple of seconds. 

People can also try the lastest SparkSDR (runs under Windows) as it has a built in programmer.

Chris, are you saying it didn't or did work for you on a 100/1000 network?

73,

Steve

kf7o

[dick_...@hotmail.com]

I was on a non routing network behind a Linksys WUMC710 Wireless-AC Bridge a Gigabit network.  The WUMC710 includes 4 outputs and does DHCP for the local net, so everything was about a foot apart.

The 2.0.4.9 version has worked in the past with my original Hermes and the other TAPR HPSDR boards.  This was on a Windows XP system

Dick

On Monday, September 9, 2019 at 6:39:09 PM UTC-7, Christopher KB3CS wrote:

[Steve Haynal]

Hi Robert,

I believe this is a PowerSDR AGC issue. There isn't even any AGC in the current HL2 gateware. As an experiment, try transmitting on Quisk, even with the LNA set high enough so that the receiver clips, and once you end transmit the RX graph and audio will pop right back up to where they normally are. I don't think I could operate FT-4 or FT-8 with the issue you describe.

73,

Steve

kf7o

[Steve Haynal]

Also, make sure that the programmer has discovered the HL2. (You have pressed discover and see the unit.) If two LEDs are flashing and two are solid then it has reverted to the APIPA address for some reason and you have probably lost the connection.

73,

Steve

kf7o

[Steve Haynal]

Hi Dick,

I don't think the version (2.0.4.9 versus 2.0.4.10) should matter as things have been stable for sometime with protocol 1. Can you try again? I'm interested if this is an intermittent or repeatable problem for people. Also, if it fails, what is the state of the HL2 LEDs, and how long did it try to erase? Finally, please try SparkSDR to see if there is any difference.

73,

Steve

kf7o

[Christopher KB3CS]

i grabbed the most recent binary published (2.4.0.10). flashing was successful both with HPSDRProgrammer and SparkSDR running on a linux box.

the only difference between 2.4.0.10 and .11 should be how long the pause lasts at the end of the Discovery phase. (12 sec vs 2 sec, respectively).

the network i have between the computer and HL2 will adapt to whichever speed either end negotiates. i mentioned an improbable but possible wrinkle with a 100Mbps-only-or-max network because of a dusty old note ;-) encountered about flashing Metis firmware while i researched the flashing protocol implementation.

with HPSDRProgrammer:

1. choose/verify the network interface for communicating with HL2

2. press the "Discover" button and wait for the "Device" field to be populated

3. choose/verify the particulars for the HL2 to be flashed

4. browse and select the raw binary file image (.rbf)

5. take a deep cleansing breath  ;-)

6. press the "Program" button

  - 2f (base 29) -

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

Hi All,

I am using 2.0.4.11 under Linux. I grabbed the source from github several months ago:

 https://github.com/TAPR/OpenHPSDR-Protocol1-Programmers.git

I have not seen this problem. My initial testing included a 100 link in the mix. I have not tried under Windows.

Erase typically takes just a couple of seconds. 

People can also try the lastest SparkSDR (runs under Windows) as it has a built in programmer.

Chris, are you saying it didn't or did work for you on a 100/1000 network?

73,

Steve

kf7o

[...]

[Takashi K]

Hi Steve,

My understanding is as follows. If my understanding is wrong, please ignore.

1) I think it's necessary that ptt (c0, bit0) is controlled by both PTT and CW KEY(s) like Hermes v3.1 gateware.

         Hermes_Tx_fifo_ctrl #(RX_FIFO_SZ, TX_FIFO_SZ) TXFC
           (IF_rst, IF_clk, IF_tx_fifo_wdata, IF_tx_fifo_wreq, IF_tx_fifo_full,
            IF_tx_fifo_used, IF_tx_fifo_clr, IF_tx_IQ_mic_rdy,
            IF_tx_IQ_mic_data, IF_chan, IF_last_chan, clean_dash, clean_dot, (clean_PTT_in | CW_PTT), OVERFLOW,

     But piHPSDR can switch Tx and Rx by not only ptt bit but also dash and dot bits.

     piHPSDR code is ;

           if(vfo[tx_vfo].mode==modeCWL || vfo[tx_vfo].mode==modeCWU) {
           local_ptt=ptt|dot|dash;
           }

     I have not checked other SDR software codes.

2)  In HL2 gateware, when CW key up, ext_cwkey (debounced CW KEY ) is negated after 6ms.

     ext_cwkey (=C0, dot bit) is sent to SDR software. SDR software switches Tx state to Rx state by it as I mentioned above.
     But at that time tx_cw_key is still asserted. HL2 transmits CW signal (that is decreasing gradually to avoid key click) .
     Therefore I guess that Rx AGC becomes minimum gain by receiving several tens dits and dahs in short period). 

73,

Taka,  ji1udd

[Jaroslav Škarvada]

I used what is marked as HPSDRProgrammerV2_nopcap version 2.0.4.11
(2014-11-9) with direct ethernet cable connection, ISC DHCP server 4.3.6
running on my laptop. The HL2 was correctly detected by the
HPSDRProgrammerV2_nopcap and I also previously used it to successfully
upgrade from the gateware version 64 to 65, but upgrading to 20190907
(version 66?) failed for me for some reason. I suppose it is
intermittent problem, but I will retry when I return from my vacation :)
(I forgot to pack the JTAG cable :)

Jaroslav, OK2JRQ

Steve Haynal napsal(a):

> --
> 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/10455580-8e14-4e22-ba3d-65d87cf06c7b%40googlegroups.com
> <https://groups.google.com/d/msgid/hermes-lite/10455580-8e14-4e22-ba3d-65d87cf06c7b%40googlegroups.com?utm_medium=email&utm_source=footer>.

[dick_...@hotmail.com]

Hi Steve.

I tried with nocap ver 2.0.4.9 and 2.0.4.10.  Also with version 2.0.3.0 that requires the nocap program.

Each program properly discovers the HL2 in about 8 seconds but all 4 lights remain on.  If I try to program it starts the erasing notification and after 3 or 4 minuets I canceled the program - there was never a change to the 4 LED's.  Yesterday it ran for over 30 minutes .  Always has the same version 64 in HPSDR ir Quisk and never a problem with these programs connecting to the HL2 no mater where on my network I place the HL2.

The only connection issue that I have observed was with the setup program that would not connect from the router [PC directly connected] to the HL2 behind the Linksys Wireless Bridge.

I have installed SparkSDR on a win 7 machine but was confused with the operation as it did not look like anything that I read about.  I will try again later today / tonight to see if I can get it working.

I had the nocap version 2.0.4.11 program at one time but deleted it because it was recommended that we use ver 10.  The TAPR site says that it is in the "archives", but I can not find them.

Dick K9IVB

[Christopher KB3CS]

wireless bridge!  perhaps you are being bitten by the UDP-no-checksum (valid UDP but not all network hardware behaves properly when presented no checksum UDP packets)?

  - 0b1001001 -

On Tuesday, September 10, 2019 at 4:30:11 PM UTC-4, dick_...@hotmail.com wrote:

[...]

The only connection issue that I have observed was with the setup program that would not connect from the router [PC directly connected] to the HL2 behind the Linksys Wireless Bridge.

[...]

[Alan Hopper]

Hi Dick,

the way it should work in SparkSDR is that on startup your radio should be listed in the top bar of options, right clicking on it should give the option to reprogram where you can select the file and program.  If  this does not happen please let me know.  A vital thing to know (whatever software you use) is once the the first stage that erases the eeprom is complete you should not power the radio down until programming completes, keep retrying until it works otherwise a blaster will be needed next time you power up.

73 Alan M0NNB

[Steve Haynal]

Hi Dick,

I tried the prebuilt 2.0.4.10 this evening with my Windows 10 laptop and was able to program the HL2 via wireless and cable connection. The HL2 is not really an openhpsdr or tapr radio. For example, it uses a modified gigabit controller from protocol2 RTL but still implements protocol 1. Many parts of the gateware protocol handling code have been rewritten. It could be that one of these differences is not playing nicely with your network for some reason. It will be helpful if we can vary a few things to try and see where the problem is.

 * Are all 4 LEDs on solid? In idle mode, one of the 4 orange LEDs should be blinking to indicate that the ethernet clock is up. Is one blinking? You will see no change during the programming process.

 * Are you using wireless or wired connections? Can you try to change the connections up on both the host and HL2 side to see if there is any difference?

 * Under Linux, I see output from the programmer when started in a shell. See below. Can you try under Linux, or enable debug/log output for the programmer? (Sorry, not sure if/how to do this for Windows. Every program should have debug output options...)

 * Even if SparkSDR fails programming too, it might provide some helpful information in the log.

So far you are the only one who has seen this problem. Jaroslav has seen it work several times and fail once under Linux. I must have programmed some HL2 at least 50 times over ethernet now and have never seen a failure.

73,

Steve

kf7o

shaynal@shiva ~ $ openhpsdr/OpenHPSDR-Protocol1-Programmers/HPSDRProgrammerV2-nopcap/HPSDRProgrammer_V2_nopcap 

"eth0" "D0:50:99:37:A7:5B" "192.168.33.200"

"virbr0" "00:00:00:00:00:00" "192.168.122.1"

Interfaces found  2

"eth0" "D0:50:99:37:A7:5B" "192.168.33.200"

"virbr0" "00:00:00:00:00:00" "192.168.122.1"

Interfaces found  2

in InterfaceSelected

"eth0"

interface addresses  "192.168.33.200"

QHostAddress("192.168.33.200")

in MainWindow::discover

discovery packet sent

in MainWindow::discover after broadcast

WriteBoard::readyRead

WriteBoard: readDatagram read  "192.168.33.245" 1024 2

Case 2

*******  0x7ffdd8b54983 67 6

6 "metis"

6 "metis"

board address "00:1C:C0:A2:13:DD (192.168.33.245) Software version: 6.7 ()"

 writeboard::discoveryUpdate 

in MainWindow::discoverUpdate

("00:1C:C0:A2:13:DD (192.168.33.245) Software version: 6.7 ()")

in boardSelected

0

"00:1C:C0:A2:13:DD (192.168.33.245) Software version: 6.7 ()"

in getIPAddress

in MainWindow::browse

in MainWindow::program

file size= 366133 length= 366336

"/home/shaynal/Hermes-Lite2/gateware/bitfiles/testing/20190907/hl2b5up/hl2b5up.rbf"

start= 0  end= 366336  blocks= 1431

sendCommand  2

before send

WriteBoard::readyRead

WriteBoard: readDatagram read  "192.168.33.245" 1024 3

Case 3

Programming device ...

sendData offset= 0

WriteBoard::readyRead

WriteBoard: readDatagram read  "192.168.33.245" 1024 4

ready for next buffer

in Mainwindow::nextbuffer

sendData offset= 256

WriteBoard::readyRead

WriteBoard: readDatagram read  "192.168.33.245" 1024 4

ready for next buffer

more of the same...

[Steve Haynal]

Hi Taka and Robert,

Thanks for the analysis. I will have to take a closer look. The receiver is disconnected from the antenna during TX so it can look like low RX if the TR relay is still in the TX position due to the CW/TX hangs you mention but the operator is expecting RX. If this is the case, you and Robert should hear the TR relay click several seconds after TX and the RX levels go back to normal. Do you hear a late TR relay click with the latest gateware?

73,

Steve

kf7o

[Steve Haynal]

Hi Dick,

For debug output under Windows, you will have to download the source, modify the .pro file and rebuild. QT is open source.

https://stackoverflow.com/questions/13431734/qt-qdebug-doesnt-work-in-windows-shell

https://www.qt.io/download

73,

Steve

kf7o

[Takashi K]

Hi Steve,

Please have a look at the attached short movie.

The using gateware is official 20190907.

While transmitting several dits, spectrum scope is chattering between transmitter spectrum display and receiver spectrum display. Also the low sensitivity after transmit several dits is recovered gradually.

73,

Taka, ji1udd

[Jim Ancona]

I've been meaning to reply to this thread. I saw behavior similar to what Dick reported. I tried to program my build8 board using HPSDRProgrammer_V2_nopcap_2.0.4.10 on Windows 10. When on a wired connection it would not recognize the HL2. (Both the PC and the HL2 were connected to an ancient Linksys 100M switch.) When I switch to wifi on the PC side (HL2 still connected to the same switch) it would sometimes (maybe once in 5 tries) see the HL2, but then would hang at the erasing stage. When I switched to using SparkSDR it worked first time over the same wired connection.

I haven't done anymore troubleshooting since I got it to work, but I can try other steps if it would help to track down the issue.

Jim

N1ADJ

--
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/dd1d54f5-feaf-4f29-9c9f-5ae2d5187672%40googlegroups.com.

[dick_...@hotmail.com]

Steve

When ever I have tried to use the programmer, all led's are on with the left one, next to the NIC jack blinking.  I found my copy of the 2.0.4.11 and tried that too with the same result.

I think I now know what the problem is, but unfortunately created another problem with the answer.  My network uses Trendnet TEG-S8g managed Gigabit switches and apparently the network does not permit the proper packets to get through.  When I set up an isolated router [W/o Internet connection] and just connected the PC and the HL2 to the router. The HPSDR and Quisk programs function properly.  The HPSDRprogrammerV2_nocap worked correctly, with the erase taking only a couple of seconds and programmed in about 5 seconds.  At the end all of the led's went black and the programmer tried to do another search which failed.  Unfortunately I think the download of the .rbf file was not correct as all the led's went blank and I think I will have to us the Blaster method to recover.

I have had problems before with getting the proper files of of the GitHub I was in the

https://github.com/softerhardware/Hermes-Lite2/blob/master/gateware/bitfiles/stable/20190616/hl2b5up/hl2b5up.rbf

folder and clicked on the "download" button and used that file to program the HL2.

I guess I will have to get my unused blaster out and reprogram that way.

How can I check that I have the right files downloaded ?  Can you do MD5 or SHA for the files ?

Thanks

Dick K9IVB

[Steve Haynal]

Hi Dick,

Sorry to hear of your troubles. There is a video covering how to program gateware with a USB blaster:

https://www.youtube.com/watch?v=5m2kUmod0yQ

I downloaded from the link you pointed to and that file came through correctly and is the correct file. I'm not sure what is happening with you and Jim. From Jim's experience, the solution is to use SparkSDR.

I'm thinking about adding programming code to the hl2setup program. This runs under Windows and Linux and is already used to set the bias and run tests. That way we could have more control and understanding of the process. I'd also like to add some postcompile customization like adding a fixed IP or different MAC to the process. User takes the released .rfb, specifies some extra parameters which are tacked on at a certain address in the EEPROM, HL2 reads these values during runtime. It is all just a matter of finding the time or a willing person...

73,

Steve

kf7o

[Steve Haynal]

Hi Taka,

Thanks for the video. It is very helpful. I will try to take a closer look at this problem this weekend. I've also made a github issue:

https://github.com/softerhardware/Hermes-Lite2/issues/121

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

here is my c# programming code that might help anyone that wants to add it to the setup program. It assumes discovery has already happened

        public async Task<bool> ProgramP1(IPAddress address, byte[] firmware, IProgress<string> progress)

        {

            return await Task<bool>.Run(() =>

            {

                try

                {

                    using (var udpClient = new UdpClient(new IPEndPoint(IPAddress.Any, 0)))

                    {

                        udpClient.Client.ReceiveTimeout = 60000;

                        udpClient.Connect(new IPEndPoint(address, 1024));

                        byte[] cmd = new byte[8 + 256];

                        cmd[0] = 0xef;

                        cmd[1] = 0xfe;

                        cmd[2] = 0x03;

                        cmd[3] = 0x02;

                        IPEndPoint from = new IPEndPoint(0, 0);

                        udpClient.Send(cmd, 64);

                        progress.Report("Erasing");

                        var response = udpClient.Receive(ref from);

                        if (response.Length >= 3 && response[2] == 0x03)

                        {

                            udpClient.Client.ReceiveTimeout = 6000;

                            progress.Report("Programming");

                            cmd[2] = 0x03;

                            cmd[3] = 0x01;

                            int blocks = firmware.Length / 256;

                            if (firmware.Length % 256 != 0) blocks++;

                            cmd[4] = (byte)(blocks >> 24);

                            cmd[5] = (byte)((blocks >> 16) & 0xff);

                            cmd[6] = (byte)((blocks >> 8) & 0xff);

                            cmd[7] = (byte)((blocks) & 0xff);

                            for (int block = 0; block < blocks; block++)

                            {

                                progress.Report("Programming " + block * 100 / blocks + "%");

                                int len = Math.Min(256, firmware.Length - block * 256);

                                Array.Copy(firmware, block * 256, cmd, 8, len);

                                Array.Fill<byte>(cmd, 0xff, len + 8, 256 - len);

                                udpClient.Send(cmd, 8 + 256);

                                // check response except for last

                                if (block < blocks - 1)

                                {

                                    response = udpClient.Receive(ref from);

                                    if (response.Length < 3 || response[2] != 0x04)

                                    {

                                        throw new Exception($"Programming failed at block {block}");

                                    }

                                }

                            }

                        }

                        else

                        {

                            progress.Report("Erase Failed ");

                            return false;

                        }

                    }

                    progress.Report("Programming Complete");

                    return true;

                }

                catch(Exception e)

                {

                    errorlog.logException(e, "Program P1");

                    progress.Report("Programming Failed");

                    return false;

                }

            });

        }

[Jaroslav Škarvada]

I have just returned from my vacation and retried - the same process,
the same SW/HW, the same cabling, just different QTH :) and now it
worked flawlessly - I successfully upgraded to 20190616 (v6.6). So it
seems there is same race or something which could trigger time to time

73! Jaroslav, OK2JRQ

Jaroslav Škarvada napsal(a):

[Steve Haynal]

Hi Jaroslav,

Thanks for the update. I will keep an eye out for this problem. Maybe there is some intermittent issue.

73,

Steve

kf7o

>> an email to hermes-lite+unsubscribe@googlegroups.com
>> <mailto:hermes-lite+unsub...@googlegroups.com>.

[Alan Hopper]

Hi Steve & Taka,

I've finally got round to optimizing Spark for the improved tx latency and am getting good results.  I'm also looking at using the ptt and dot/dash signals from the radio and just wanted to understand what they do and what is expected from the software.  If the ptt is triggered on the radio is the radio switched to tx directly or is this just a signal to tell the sw to start tx? When a keyer is being used in the radio I assume tx/rx switching happens in the firmware, does the ptt from the radio then change and if so what should the software do ( I assume sending ptt back to the radio could cause issues but the sw would then need to know the keyer is in use to not do this ).  Sorry for being lazy and not studying the rtl.

73 Alan M0NNB

[Amogh Desai]

Hi Steve and Alan,

I just updated to the latest testing release and see an issue on transmit.  Here's a screenshot of v66 and v67.  66 works without any issues, but on v67, transmit acts weird.  I have tried transmitting in ft8 and sig mode give distorted output whose power also keeps changing from 3-5.5 watts.  SSB waveform on screen looks ok but there is no power output.  I have tried moving back and forth from v66 and v67 and the issue persists with v67. This is on sparksdr.  Quisk seems to work fine.

Here's a screen shot of 66 vs 67 transmit screen in sig mode.

[Alan Hopper]

Hi Amogh,

a bit of a shot in the dark but have you tried the 2.0.0.7 release of Spark http://www.ihopper.org/radio/previews.htm, it does fix a couple of bugs related to rf agc, not sure how the firmware will affect this but might be worth a try if you are not already using it.

73 Alan M0NNB

[Alan Hopper]

Hi Amogh,

I notice from you screenshots the power and swr readings are a bit crazy what hardware do you have? Also you appear to have sync errors (ep6) on the bad picture which could be an indication of a problem.

73 Alan M0NNB

[Amogh Desai]

Hi Alan,

I have a HL2b6. 2.0.0.7 fixes the issue.

73

Amogh

VU3DES

Regards, 
Amogh Desai
www.amoghdesai.com

--
You received this message because you are subscribed to a topic in the Google Groups "Hermes-Lite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hermes-lite/WTZFXb5O40U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/bc7b9582-f832-4879-925b-bc134c995fc5%40googlegroups.com.

[Alan Hopper]

Hi Amogh,

I'm glad that worked but I can't really explain why it would now I think about it more :). I am intrigued with your reverse power and swr numbers  do you have a short or something reversed?

73 Alan M0NNB

On Sunday, September 29, 2019 at 7:15:24 PM UTC+1, Amogh Desai wrote:

Hi Alan,

I have a HL2b6. 2.0.0.7 fixes the issue.

73

Amogh

VU3DES

Regards, 
Amogh Desai
www.amoghdesai.com

On Sun, Sep 29, 2019 at 11:16 PM 'Alan Hopper' via Hermes-Lite <herme...@googlegroups.com> wrote:

Hi Amogh,

I notice from you screenshots the power and swr readings are a bit crazy what hardware do you have? Also you appear to have sync errors (ep6) on the bad picture which could be an indication of a problem.

73 Alan M0NNB

--
You received this message because you are subscribed to a topic in the Google Groups "Hermes-Lite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hermes-lite/WTZFXb5O40U/unsubscribe.

To unsubscribe from this group and all its topics, send an email to herme...@googlegroups.com.

[Amogh Desai]

Hi Alan,

The swr numbers are incorrect as I haven't populated the swr sense diodes/torroid yet. HL2b6 was only supplied as a exciter board. I got the N2ADR filter board saperatly and still haven't got hold of the torroid here.

About ep6 numbers. They only increased (very rapidly) during transmit with the old version/new firmware. During rx it was stable. 

Regards, 

Amogh 

VU3DES 

To unsubscribe from this group and all its topics, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/82e16af2-d1d5-439a-a602-48665be57ace%40googlegroups.com.

[Takashi K]

Hi Alan,

Dot / Dash signals are used when using the keyer function provided on the SW side.

>If the ptt is triggered on the radio is the radio switched to tx directly or is this just a signal to tell the sw to start tx?

The radio is switchd to tx directly.

73,

Taka,  ji1udd

[Steve Haynal]

Hi Alan,

For PTT and dot/dash from the radio, nothing is expected from software. PTT switches the radio to TX directly and sets the response PTT so that software knows PTT is occurring. The same direct hw is true for the dot/dash. 

The change I made a couple of weeks ago to be more compatible with openhpsdr was related to PTT during CW use. Before only the dot or dash was sent during CW. Now PTT is always set for any type of transmit, and either dot or dash if sending CW.

The protocol specifies hang times for CW which are honered.

The HL2 doesn't yet implement the full keyer. That is planned although not first on my list.

There is also a fast CW mode where the low order TX audio bits (since they are unused in CW) indicate dot or dash. I intended to connect the internal keyer up to this. If this is not low latency enough, we can add an async short UDP packet to a new port that also does the same.

73,

Steve

kf7o