Multiple Coherent Hermes-Lite 2.0 Radios

[Steve Haynal]

Hi Group,

I was able to setup a HL2 as master with clock out on CL2 and another HL2 as slave with clock in on CL1. I can see on my scope that the clocks are synchronized in this configuration, and not synchronized if they are using independent oscillators. But I also see that when synchronized the phase difference is random (but remains constant) and depends on when the slave radio locked to the new clock. Three attempts showed three different phase relations. It is possible to bypass the PLL in the slave radio for a guaranteed phase relation, but then jitter will probably increase, especially as the number of radios in the chain increases. Jitter cleaners actually use PLLs and my first preference is to setup the slave radio with similar PLL to the master. It is possible to skew the clock output of the slave radio, but I can't think of a way to skew to align without a scope or other wires connected. Software can be clever and work around this, but it would be easier if more parameters were deterministic. What do you think?

Here is a picture of the synchronized clocks:

73,

Steve

kf7o

[Matthew]

Hi Steve,

I think for the early experiments and vast majority of users, I see the following; only 2 HL2s physically located right next to each other which could have wire links between boards. Therefore, it would be interesting to understand the magnitude and impact of the jitter with the PLL bypassed in the secondary radio (and with only 1 secondary radio). Are you proposing bypass in software, i.e. EXT clock input still routes through U6 on the secondary? Or, remove J5, J22 on a secondary HL2 and jumper the uFL CL5 to CL4?

So under the assumption wire links between radios are possible, can we attempt to skew the secondary clock based on some sort of HW sync wire on I/O between the 2 boards?

Clever things in software could be possible. However, we would need some sort of reference signal for this? It occurs to me that the low power out from 1 HL2 linked back to the other could work, but there would need to be some relay switching out antennas and to go into "calibration mode"? T

If my method of an application between the HL2s and the PC software works, then for things like PowerSDR (to avoid PowerSDR code changes), this clever stuff would need to be done in my application. I wasn't planning on this doing any DSP really, but it is possible.

I would prefer to see deterministic rather than stochastic behaviour from the HL2s rather than correcting for it in software. But if we are forced down the software route it seems possible.

73 Matthew M5EVT.

[Alan Hopper]

Hi Steve,

that sounds like good progress. Maybe we can compare with and without the pll to see if there is an issue with jitter as constant phase would be simpler. I've been pondering using know external signals (e.g. broadcast) to do a simple calibration.  I've just put up a second antenna to start testing with the Orion.  The new antenna is an inverted L tuned for 80m which meant I could join the local 80m net for the first time in a very long time, trying to copy some people on the net has given me real motivation to get this working (and to make the spark nr work better with weak signals).

73 Alan M0NNB

[Matthew]

Hi Alan,

I've also been thinking about external signals, but you would need to code in some (a lot of?) geographic dependencies in to the code for other users?

I've mentioned it before on another thread, I highly recommend a LoG antenna for 80m (or general rx on 40m or below) for rx in an average UK plot. I have a big SNR improvement with this and my 80m inverted l. Plus, if you don't already have some, the GM3SEK common mode chokes make a big difference for me with an inverted l.

73 Matthew M5EVT.

[in3otd]

Hello,

I agree that most of the time there will likely be only two H-Lv2 that need to be synchronized, so it could make sense to bypass the VersaClock completely on the slave radio and provide its reference clock directly to the AD9866 using CL2 on the master radio.

I'm not sure if going thru the slave radio PLL or not will make a significant difference: the clock coming in is generated by the same VersaClock part so cascading a similar second PLL may not provide a cleaner clock.

73 de Claudio, DK1CG / IN3OTD

[Alan Hopper]

Hi Matthew,

my initial thought for crude calibration would be to just search for a phase setting that minimizes or maximizes your nearest broadcast station. This does not do lots of things but might mean settings were valid between sessions.  I like the look of the LoG, you now have me wondering if I can squeze 2 in :)

73 Alan M0NNB

[Matthew]

Hi Steve,

I have dusted off my scope, soldered a uFL connector to CL4 and removed J22. CL4 on my secondary HL2 is connected to CL2 on my primary HL2. I've got 2 physically spaced antennas connected for receiving on. I turned everything on... I've think I've now realised that the external clock output is not enabled by default. So I've stalled for now.

I've had a look the datasheet for the U6 and the programming guide, but I'm rather confused. I've always struggled with big memory map documents like this. Should I change my output drive voltage if I connect to CL4 rather than CL1? Any chance you could post some pseudo code you have used for these experiments please (for this scenario and with clocks linked through only CL1/CL2).

73 Matthew M5EVT.

[in3otd]

Hello Matthew,

you could take a look at the Quisk code, as it has a couple of functions to set the VersaClock (auxiliary) output, see also here.

I don't think you need to change the output levels if you connect to CL4, as you need the same level that's normally on the VersaClock OUT1.

73 de Claudio, IN3OTD / DK1CG

[Ronald Nicholson]

You want a station that's orthogonal to the plane between pairs of antenna's.  Depending on the signal, by doing a careful phase analysis of the FFTs of the output of the two receivers, one should be able to sync the two receivers to within a fraction of an IQ sample, assuming clocking of the same source.

Even with sync'd receivers, one might have to do this anyway, to calibrate out different antenna matching circuits, feed line lengths, velocity factors, antenna geometries, GPS position accuracies, and etc.

73,   Ron  n6ywu

------

[Matthew]

Thanks Claudio that pointed me to some code that worked for enabling CL2 clock out. This now works. Now time to see if everything joins together and works.

73 Matthew M5EVT.

[Matthew]

Hi Alan,

Do you have your Orion setup working with 2 different antennas and SparkSDR? Are you effectively nulling out signals?

I have the following setup:

- Modified version of linHPSDR with WDSP diversity code added.For testing, using hpsdrsim and the diversity option, I can null the simulated noise. So I have moderate confidence I am extracting the rx packets and processing them in the correct order. In my early development I got a good understanding of the behaviour if you are 1 packet out of sync!

- I have written an application called hl2cluster that setups up my primary and secondary hl2. It then waits for a discovery packet from the PC. Then forwards packets from the PC to each hl2, and sends back packets from the hl2s in a single packet. I am looking at the protocol 1 sequence number and comparing for both HL2s. There is no code to re-align if things get out of sync (yet). But with linHPSDR I haven't found this to be an issue yet. A quick test with PowerSDR showed this will need some work due to the way PowerSDR sends a large dump of packets to the HL2 in a short space of time.

- I have clock CL2 from my primary connected to CL4 on my secondary and J22 is removed. My rigol scope is a 50 MHz scope with a firmware mod to open 100 MHz. I'm using the stock probes. Looking at the VersaClock signals is pushing the metrology limits of my scope. I don't really feel I can comment on jitter with this. Probing CL4 on both boards the clocks look around 10-20 degrees out of phase. I wasn't expecting this. It would be good if someone else could repeat these measurements.

- For my tests, I have a 20 m half wave dipole in my attic (N-S), and a 110 ft doublet in my garden (E-W). I have other options and can setup verticals and an active antenna, but this was the path of least resistance for now.

I joined everything together last night and I'm not convinced I have everything setup correctly. I've never really used this type of setup before so I don't really know what to expect. There are some videos on YouTube that suggest it should be a rather pronounced effect, but I suspect this is very dependent on antenna setup when it comes to noise cancelling (e.g. a "poor" antenna just picking up the noise). I may need to revisit my understanding of the maths of this, but I was working under the assumption that as long as the clocks are phase locked, phase offset doesn't matter for noise cancelling. Is this a flaw in my understanding?

With everything connected, I took a local problem noise source and adjusting the gain and phase, I could see some effect. Keeping the gain locked and changing the phase, I could change the signal strength of this noise source, it wasn't very pronounced though. This makes me think I may be doing something correct. If I then changed to an SSB signal on 20m, I couldn't really change the received signal much at all by playing with the gain/phase setting. I tried a few signals and had the same experience. Right now I have too many unknowns to convince myself everything is working.

I'm trying to tidy my code to a point that I can put it on github so that others can join the experiment.

73 Matthew M5EVT.

[Jonas Sanamon]

Hi Matthew.

Your experiences are in line with what I've seen with PowerSDR and my ATLAS-based HPSDR rig with 2 mercury receivers.   I think for best effect of the diversity and nulling features I ought to have 2 similar antennas, so I have in my long term plan to install the 2 active receive antennas I have on the shelf. Preferably something like 100m apart.

I'm certainly no expert, but having clock phases locked but with an offset must be OK, that should just be the same as having a longer coax cable on one of the antennas, right?

Best Regards,

Jonas - SM4VEY

--
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/34d51f1d-9fa6-45cf-8d20-b6a5acbe1ada%40googlegroups.com.

[Alan Hopper]

Hi Matthew,

I have only just made the leads so I can connect both antenna at once. I've had a very quick play with Thetis (as I was working on P2 on the orion) and can null out a broadcast am station completely or reduce the noise slightly but some odd things happen. If I restart the program the phase has to be adjusted, if I tune away and then back again the phase has to be adjusted, It is probably an old version of Thetis. I'll try with Spark and the old protocol later now that I have a reference. I've not put diversity in the new protocol as the restrictions on which receivers/adcs that can be sync'd are a bit of a challenge to Spark's use any receiver for anything approach and needs some more thought.

I'll report back when I've played further and hopefully understand things better.
73 Alan M0NNB

[Ronald Nicholson]

Local noise nulling is often done with 2 different antennas.  One small antenna in the midst of the RFI/EMI noise sources, and then a larger antenna farther away from the local RF noise sources, if possible.  Or the two antennas can be oriented so one picks up more RF noise than the other (directional, or vertical vs. horizontally polarized, etc.)

Clock phase sync is mostly useful with carefully matched feedlines and well matched antenna characteristics.  Otherwise, the time differential needs to be calibrated out anyway.

73,   Ron   n6ywu

To unsubscribe from this group and stop receiving emails from it, send an email to herme...@googlegroups.com.

[in3otd]

Hello Matthew,

just to verify that everything is working as it should you could try feeding both H-Lv2 with a common signal from a signal generator, in this case you should be able to clearly see the effect of changing the relative phase and gain between the two radios. You might even use the unused CL2 output on the slave radio for this, suitably attenuated of course. And then you could also play with the relative attenuation/cable lengths between the two radios inputs.

73 de Claudio, IN3OTD / DK1CG

[Matthew]

Hi Claudio,

Yes, a signal generator is a good idea. I think I was a bit blinded by all the software that I forgot some of the basics like this. I'll set this up on my bench.

I setup a 20 m 1/4 vertical today about 40 m away from my 20 m dipole. This was better than my previous experiment. I was able to find clear peaks and minima in signal strengths by changing the phase. I was also able to really improve the SNR of some MW AM stations. As others have said, I think antennas are a very important part of this system.

73 Matthew M5EVT.

[Steve Haynal]

Hi Group,

Just a quick update. I've been playing around with the Versa5 this weekend and learning a lot. I believe we can now have synchronous clock, CL2 master out to CL1 slave in without having to remove J22 and using CL4. I prefer this as it doesn't then relegate the second HL2 to always be a slave. I plan to post a set of Versa5 "recipes" on a wiki page hopefully sometime this week.

Having the two ADC/DAC clocks synchronized is a first requisite, but it is often the case that internal phase (or angle) of the NCOs are also synchronized, and the relationship between the two ADC streams is known. (Are the streams both at the same time, or is one offset by several samples?) To help with this next level of synchronization, we can connect DB12 master to DB12 slave, but I've been thinking how close we can make the synchronization without these wires. Can we use a UDP broadcast packet similar to the existing discovery packet to reset both HL2s at nearly the same time? I modified the gateware to generate a pulse in the ADC clock domain when a discovery packet is received. I then looked at the time difference between two radios. I have a cheap TL-SG1008D switch and the UDP broadcast appears deterministic from each ethernet jack. For ethernet jacks right next to each other, the discovery packet was at the same time. But for jacks separated a bit, there was some constant 10-20 ethernet domain clock ticks of separation. For the two neighbor jacks where the discovery packet is sent at the same time, there is no guarantee that the reset in the ADC clock domain will be at the same time. Both HL2s have 25MHz crystals for the ethernet PHY. These are not synchronized. But I think we could guarantee that the reset in the AD9866 clock domain is always 2 or less ticks separated with this method. What do people think?

73,

Steve

kf7o

[Alan Hopper]

Hi Matthew,

I've now tested on Spark and get the same level of nulling and noise reduction as Powersdr/Thetis so I guess I'm doing much the same thing. I still have some work to do to mantain phase when adding receivers etc. I did notice that when the sync is badly wrong (like if I don't align buffers on adding receivers) the cancellation goes a bit odd, it becomes a bit of a comb, you can cancel an am carrier and then just regular narrow notches in the signal, this might be a useful thing to look for in troubleshooting.  I have a HL2 stuck in transit between me and Heathrow, I'm looking forward to having two to sync and trying your Orion server.

73 Alan M0NNB

[Sid Boyce]

Hi Alan,
UPS again?
I tried to pay customs duty online and failed.
Gave them a call and transaction done over the phone last Wednesday, my
bank statement agrees.
This morning they slipped a note through the letter box saying payment due.
Spoke to them again on phone, they agreed I already paid and promised to
call me back in an hour - that was over 4 hours ago.
Tracking status says they will deliver tomorrow ... still says payment
due so I'll see what tomorrow brings.
73 ... Sid.

On 26/05/2020 13:01, 'Alan Hopper' via Hermes-Lite wrote:
> Hi Matthew,
> I've now tested on Spark and get the same level of nulling and noise
> reduction as Powersdr/Thetis so I guess I'm doing much the same thing.
> I still have some work to do to mantain phase when adding receivers
> etc. I did notice that when the sync is badly wrong (like if I don't
> align buffers on adding receivers) the cancellation goes a bit odd, it
> becomes a bit of a comb, you can cancel an am carrier and then just
> regular narrow notches in the signal, this might be a useful thing to

> look for in troubleshooting.  I have a HL2 stuck in transit between

> me and Heathrow, I'm looking forward to having two to sync and trying
> your Orion server.
>
> 73 Alan M0NNB
>
> On Monday, May 25, 2020 at 8:57:58 PM UTC+1, Matthew wrote:
>
> Hi Claudio,
>
> Yes, a signal generator is a good idea. I think I was a bit
> blinded by all the software that I forgot some of the basics like
> this. I'll set this up on my bench.
>
> I setup a 20 m 1/4 vertical today about 40 m away from my 20 m
> dipole. This was better than my previous experiment. I was able to
> find clear peaks and minima in signal strengths by changing the
> phase. I was also able to really improve the SNR of some MW AM
> stations. As others have said, I think antennas are a very
> important part of this system.
>
> 73 Matthew M5EVT.
>

> --
> 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/bb76b056-503b-4140-9e84-75144ea4fa54%40googlegroups.com
> <https://groups.google.com/d/msgid/hermes-lite/bb76b056-503b-4140-9e84-75144ea4fa54%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

[Matthew]

Hi Alan,

Yes I have seen some strange shapes and behaviour when I had my streams out of sync early in my development. I'm still not sure what the best device to emulate with this server is for PowerSDR. I'm sticking with it discovering as an HL2 for now. I'll probably add something to the discovery packet to let software setup for extra things like ADC select and diversity options.

Have you checked you have enough SMA cables and adapters for x2 HL2s and synced clocks? I was lucky to just find enough hidden in drawers!

73 Matthew M5EVT.

[Matthew]

Hi Steve,

This sounds like very good progress. I agree removal of J22 is not ideal so that is great if we have a way to avoid this and use the external SMAs. Your code within quisk for the VersaClock was sufficient for me in terms of detail for a "recipe".

I like your idea with a UDP packet to sync. I guess there is a risk with this that we become reliant on properties of external hardware, but with a few of us trying this we can understand if there is any variance in hardware? How were to you measuring this time difference, were you probing a line on each HL2?

73 Matthew M5EVT.

[Steve Haynal]

Hi Matthew,

Yes, I generated an external output from each HL2 in the AD9866 clock domain when the UDP broadcast was received and could compare that on the scope. I'm leaning to a modified discovery packet for the "reset" but with the ability to refine that to exact by connecting DB12 to DB12.

73,

Steve

kf7o

[Alan Hopper]

Hi Matthew,

I think I'm ok on the sma front, the second antenna challenged my stores though, 2m short of the ideal length of coax so I can't shut the shack door :) In my search I did find a roll of cable ideal for a pair of LOG antenna . I wonder if the bad behaviour when not sync'd can be measured and used for auto sync.  

I can see that emulation is a bit tricky, to fully emulate the orion and its ability to have any rx on any adc you probably have to pretend the pair of HL2s only has as many receivers as a single HL2, I guess this is not an issue for PowerSDR as it does not support lots of receivers anyway. In spark with 2 4rx HL2s I would like to be do things like use 6 rxs without phasing and just have a pair combined, In typing this I've realised all the issues of sync with different numbers of rx on each radio. I guess keeping it as simple as possible for now is the way to go. I'm finding it hard enough to tune virtual receivers without loosing sync.

73 Alan M0NNB

[Alan Hopper]

Hi Matthew & Steve,

I had a frustrating time trying to get my Orion to tune without loosing sync, I eventually found out that the Common Mercury Frequency cc bit is used to lock the rx0 & rx1 frequencies together to maintain sync whilst tuning. This makes life tricky for Spark as it assumes all receivers can do everything. I guess we need to consider what happens when you tune with multiple radios, not a problem if you tune in sw rather than with the radio (like ctun in PowerSDR) but I'm not sure if all sw has this option. For some uses this may not be a problem if you are happy to adjust the phase once tuned to a station. How do people actually use the diversity control in PowerSDR? Maybe I am worrying about absolute sync too much.

73 Alan M0NNB

[Matthew]

Hi Alan,

I had a light bulb moment of the usefulness of CTUN when I started looking at diversity. linHPSDR has it. I envisage I would set the sample rate to to something to cover a whole CW segment, turn on diversity and just use CTUN.

The way I have handled the "all receivers can do everything" problem in linHPSDR is that when diversity is turned on, a new receiver is added, but this is hidden from the user. Then all the vfo sync etc. is handled in the software. I think locking rx's vfos should be done in software and not anywhere near the FPGA. This adds more gateware and/or we end up with a poor design of being stuck with certain receivers only doing certain things (like how the HPSDR protocol deals with PureSignal...).

Incidentally, could you run a quick check what happens with this bit set and sent to an HL2? I accidentally had this set for some of my diversity development in linHPSDR and it did strange things to my HL2. If you can replicate this, I'll file an issue on github.

73 Matthew M5EVT.

[Alan Hopper]

Hi Matthew,

I was locking the vfos in sw and making sure they were sent in the same udp packet but still loosing sync on tune, there is a note in the Orion gateware about a bug here hence the use of this bit. It was driving me mad that I could tune in PowerSDR but not Spark.  I have a magic number I can tweak to limit hw tuning in spark, if you have more than one virtual receiver on a real receiver it already only tunes when it really has to so I can live without hw tuning working perfectly.  Should get my HL2 on Friday.

I'll try the bit on HL2, what should I look for?

73 Alan M0NNB

[Matthew]

Hi Alan,

I saw a nice comb pattern on the rx panadapter in linHPSDR when I enabled this and the receiver I was using appeared to have a corrupt IQ stream.

73 Matthew M5EVT.

[Alan Hopper]

Hi Matthew,

yep that bit breaks HL2 for me as well.

73 Alan M0NNB 

[Steve Haynal]

Hi,

There was some leftover code from when we had 32 receivers that used that bit. I removed it and a fix where that bit does nothing should be in the next release, hopefully this weekend.

73,

Steve

kf7o

[Matthew]

Thanks Steve, it means one less "if" in code for an HL2 case.

I had hoped to tidy up my diversity code a little more before the weekend (CQ WPX CW), but I've run out of time now. If anyone wishes to experiment with this, please read the following.

This application takes n HL2s (where n must must >1) and sends a single IQ rx stream to the PC. I took out my ADC selection code for now, so it is simply HL1 = rx0, HL2 = rx1 etc. The code in here sets up the primary HL2 to output a clock on the EXT clock connect. The secondary HL2 must have uFL connector fitted to CL4. CL2 on the primary is connected to CL4 on the secondary and J22 is removed. If anyone wants to experiment with the VersaClock i2c code, it is in HL2radio.cpp around line 151 onward. I intend to modify this in future with Steve's new way of doing this not removing J22.

You'll need to modify hl2cluster.cpp and within main. Change the char to the interface you wish to discover on. Please read the README. Keep an eye on the terminal output, this should tell you if things aren't good. I recommend not starting this application and the SDR software at the same time. This can mess up my crude discovery code. I still haven't satisfied myself I have covered all possibilities of getting out of sync for sending packets onward to the PC. I think this will only work well for now with SDR software that schedules packets to the HL2 (SparkSDR, quisk, linHPSDR, NOT PowerSDR). I have stuck at 48000 sample rate to reduce load. Alan, I think in the current state, it should work with SparkSDR.

https://github.com/m5evt/hl2cluster

I will do more work on this code next week.

The experimental version of linHPSDR to interface to this can be found here:

https://github.com/m5evt/linhpsdr/tree/m5evt-diversity

The bookmark button has been temporarily replaced by "DIV", this enables diversity. It adds a new hidden rx and the vfo is synced to the parent rx. Again, read the terminal to check it is behaving as expected. There is a bug that sometimes when diversity is enabled, the hidden rx doesn't sync. I recommend changing frequency (click somewhere in the rx panadapter) after enabling diversity to guarantee sync. Turning off diversity deletes the hidden receiver. Deleting a receiver sometimes causes linHPSDR to crash. This bug has been there for a while and I must fix this. There is more work to do with the code.

73 Matthew M5EVT.

[Alan Hopper]

Hi Matthew,

thanks for that, I now have a second HL2 here but also don't have much time over the weekend. I think I'll hold off modifying my radio and look at the CL1 CL2 solution.

73 M0NNB

[Steve Haynal]

Hi Matthew and Alan,

Thanks for the update and code. I might get a chance to look at it this weekend, but also want to finish up some gateware changes to facilitate this. I have good clock synchronization with CL1 and CL2 now. It is in gateware I am just about to release. I will document it tomorrow. I had to add a reset bit to the gateware as I couldn't reset it properly from softwrae.

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,Matthew & All,

there is a new version of Spark v2.0.1.8 here http://www.ihopper.org/radio/previews.htm that has basic coherent support for the hpsdr Orion board and may work with Matthew's server if you make it report as an orion. I've only posted a windows build, the rest should follow this weekend.  I've also added the ability to change mac and ip which has been on my list for ages and is needed with multiple radios.

73 Alan M0NNB 

[Steve Haynal]

Hi Alan, Matthew and Group,

I've documented my experiments with setting up synchronous clocks:

https://github.com/softerhardware/Hermes-Lite2/wiki/External-Clocks

This uses CL1 and CL2. I'm pretty happy with the results. The clocks are well aligned on my scope. There is a skew number which can be set to fine tune the alignment.

I am working now on the next level of synchronous reset of the phase accumulators. I decided to implement the CN12 to CN12 connection. It will allow for ~150Mbps communication eventually as well as synchronous resets. The ribbon cable should not be longer than 30cm. Note that on one radio the red wire is nearest the ethernet side of CN12 but on the the other radio it is farthest from the radio. I am using a spare 10 pin cable here but only a 6 pin cable is needed.Something like this:

https://www.amazon.com/Sydien-2-54mm-Connector-Ribbon-Length/dp/B07Q2SX5CX

73,

Steve

kf7o

[Matthew]

I've re-connected J22 on my HL2 and quickly updated hl2cluster to use the new method of CL1/CL2 SMAs to sync clocks:

https://github.com/m5evt/hl2cluster

It appeared in sync on my scope. A quick check with SparkSDR confirms that if you change line 161 of HL2server.cpp, from:

unsigned char reply[20] = {0xef, 0xfe, 2, 0xaa, 0xbb, 0xcc, 0xdd, 0xff, 0xff, 73, 0x6,

to

unsigned char reply[20] = {0xef, 0xfe, 2, 0xaa, 0xbb, 0xcc, 0xdd, 0xff, 0xff, 73, 0x5,

The device discovers as an Orion it works with SparkSDR.

Just a quick update, much more work to be done on this and it still remains experimental. Windows SparkSDR users may be able to get this to work by running hl2cluster on an rpi, but I've not tried this.

73 Matthew M5EVT.

[Alan Hopper]

Matthew,

I'll echo your experimental comment here, for starters I've discovered I have a tuning bug if you use multiple virtual receivers with some having different or two adcs, fixed here but not in v2.0.1.9 .  I live in a fairly rural setting and am starting to wonder if the reason I'm not seeing much noise reduction is because I don't have much noise:)  I did some work on a chirp mode a few years ago and am thinking of dusting it off and turning an HL1 +RPi into a portable calibration source and a reliable moveable local signal that I can try to null or reinforce(perhaps running wspr).

73 Alan M0NNB

[Steve Haynal]

Hi Matthew and Alan,

Just a quick update on my efforts working from the gateware up to support synchronization. I ran into some problems when enabling the LVDS links. This particular FPGA requires you to give up an additional nearby IO when using LVDS, plus the differential clock inputs don't support registers when used for LVDS data. Because of those learnings I've decided to just use single-ended IO for this link. At 2.5V and ~30cm, we should still be able to get ~150Mbps total, but in the worst case this may drop to ~75Mbps. But for the initial resets we don't really need bandwidth.

I am working towards 2 reset mechanisms. One uses a modified global discovery packet and should be able to sync the internals of each HL2 to within 0 to 2 clock ticks. The other uses the DB12/DB12 link and should sync both HL2s exactly. It will be setup so software can send both resets and not need to know if the DB12/DB12 cable is installed.

I also realized that reset is more involved then just clearing the phase accumulators. I need to flush all the buffering to make sure the samples in the packets from each radio are aligned.

I don't have a good solution for handling frequency changes except to resync after every frequency change. This is why the original protocol allows you to lock two receivers. It will be harder for us as the two receivers are not controlled by a single FPGA but by two, so the communication of the frequency change must be synchronous.

As this develops, maybe we can not just clear the phase accumulators, but load specific values, etc.

I once asked Analog Devices whether two AD9866s could be used in synchronous fashion. They said the AD9866 was not designed for this so there were no guarantees, and then pointed me to another part. There could very well be some nondeterminism in the data delays from each AD9866 that we will discover.

73,

Steve

kf7o

[Matthew]

Hi Steve,

This sounds like some good progress you have been making on the gateware, thanks.

With regard to your last sentence, I am very much viewing this as an experiment that might just not pan out how we expect. However, I read your message with all the future work and asked myself "how far out" are we at present?

Going back to Claudio's very fine comment regarding use of a signal generator, I have setup my signal generator. This is a miniVNA. I can adjust the phase of each output. I set an arbitrary phase difference and set about seeing how well I could cancel two signals out of phase. I could achieve near enough full cancellation. See attached screenshots for ADC1 (HL2 #1), ADC2 (HL2 #2) and ADC1+ADC2 (phase cancellation)

What I did observe was that to get the last 10 dB of cancellation required very fine tuning that could not be achieved with the clicking on the circle in SparkSDR. Secondly, at this minimum, the carrier was varying in amplitude from below the noise to about 5-10 dB above at worst. I can't be sure this isn't my signal generator.

The subtle point I had missed in this until I read your message in detail was synchronisation beyond the ADC in the FPGA. With this setup described above, I moved +15 kHz and then back -15 kHz. The cancellation was now virtually non-existent. However, as I have stated in messages above, a CTUN like button for changing frequency with the IQ passband means we don't have to change the HL2 receiver frequency.

73 Matthew M5EVT.

[Alan Hopper]

Hi Matthew & Steve,

Great to see it working in Spark, I've failed to document that holding the mouse button down over the middle white circle then controls phase left and right and gain up and down with movements of the mouse with finer control. I'm working on something better, It is tricky and I think some automation might help.  I think we are already at something useful if you are prepared to tweak once on a signal. 

Steve, your direction all makes sense to me and I'm enjoying the experimentation, I guess we will gently work out what really matters and what we can get away with.  I'm spending a lot of thought on how to best integrate with Spark and multiple radios, antennas etc.

73 Alan M0NNB

[Steve Haynal]

Hi Matthew and Alan,

Thanks for the update. The results with SparkSDR look great!

73,

Steve

kf7o

[Steve Haynal]

Hi All,

I did spend a little time on this over the weekend. Here is a quick update.

I did 30+ trials of global synchronous reset with broadcast UDP. 78.8% of the time the reset pulses occurred at exactly the same time, 12.1% of the time the reset pulses differed by one clock tick due to different (noncoherent) ethernet crystals in each unit, and 9.1% of the time the reset pulses differed by 100s of clock ticks probably due to code polling or interrupts in the switch processor. Because of these variations and the need for several types of resets, I've abandoned trying to use a broadcast UDP for synchronization. Instead, I am relying on a DB-12 to DB-12 connection via 6-pin ribbon cable as originally planned. 6-pin ribbon cables are common and inexpensive, and the 30cm ones I bought on Amazon appear to work fine.

With the DB-12/DB-12 connection, I now have reset pulses that are synchronous 100% of the time. These can reset the phase accumulator in each NCO. But this is not enough as the streams from both units should be aligned (sample M in packet N from both streams are coherent), and the decimation counters in various filters should also be synchronized. I've outlined how I'd like to do all of this and am (slowly, when I find time) implementing a first cut.

73,

Steve

kf7o

[Matthew]

Thanks for the update Steve. After some crude tests with various quickly thrown together antennas with the x2 HL2 setup, I've decided to pursue some active vertical antennas. I've been looking at various low-noise high Z amplifier designs. I find these simple (yet subtly complicated) circuits very satisfying to study, understand and build. Also, without a doubt, much cheaper to build yourself than buy some of the commercial offerings!

73 Matthew M5EVT.

[Rune Øye]

Hi Matthew,

There is no much help I can provide in terms of coding etc however if you want, I can spare you two circuit boards, BN73xxxxx.202 cores and the AD8055ANZ op amp.

The other parts should be easily available in UK. I have used this OP AMP with a simple ground rod and 5-6 meter fiberglass rod using 1.5mm wire as the element.

I have used this for my 9-circle array or for any experiment with i.e. two element inline to rotate 360° with a DX engineering phase box. Also used four antennas as 2-element broadside end fire (like in an 8-circle array)

You need a sort of DC injector to your coax or two small batteries at the antenna and they will last for a long time. (I guess I have 100nF and 470uH for DC injector as well if you need)

2 x equal antennas with 2 x equal coax into each HL-2 you can have a lot of fun :-)

   

https://static.dxengineering.com/global/images/instructions/dxe-yccc-3inline.pdf

When I see there is a solution for Diversity, I will order my second HL-2.

This is how I can help so you can experiment and get  the 2 x HL-2 going in Diversity :-)

 

73,

Rune LA7THA

--

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/8bca1f5e-a051-429f-a6a5-bfe99ce26169o%40googlegroups.com.

[Matthew]

Hi Rune,

Thanks very much for your kind offer. I've actually got everything here in drawers, including the cores and op amps (well, I actually have a nice op amp left over from something else with lower V/Hz rating than the AD8055). Some people call it a junk box, but I call it a treasure box. I also have a homebrew DC injector in a Hammond box from a previous homebrew project too.

I am very much looking forward to some low band experiments with this setup in the winter. Listening on the LF bands at the moment and hearing the non-stop stream of static crashes reminds me that summer is the time to focus on optimising my LF setup ready for the winter.

73 Matthew M5EVT.

[Rune Øye]

Hi Matthew,

All good, you have a drawer with "junk" as well :-) may I ask what OP AMP you are using ?..... all my RX antennas were checked in April / May so ferly ready for the upcoming TB season :-)

Let's hope we can have  2 x HL-2 working in Diversity...

73,

Rune

--
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/e20576de-6296-4ed6-9ef4-568e8747c232o%40googlegroups.com.

[Matthew]

Hi Rune,

I have a few ADA4817 spare so I will try these. But there are newer op amps that look very good e.g. LTC6228. All SMT so you would need to make some sort of adapter PCB to fit an AD8055 footprint.

73 Matthew M5EVT.

On Wednesday, 17 June 2020 08:46:58 UTC+1, Rune Øye wrote:

Hi Matthew,

All good, you have a drawer with "junk" as well :-) may I ask what OP AMP you are using ?..... all my RX antennas were checked in April / May so ferly ready for the upcoming TB season :-)

Let's hope we can have  2 x HL-2 working in Diversity...

73,

Rune

tir. 16. jun. 2020 kl. 23:21 skrev Matthew <bal...@gmail.com>:

Hi Rune,

Thanks very much for your kind offer. I've actually got everything here in drawers, including the cores and op amps (well, I actually have a nice op amp left over from something else with lower V/Hz rating than the AD8055). Some people call it a junk box, but I call it a treasure box. I also have a homebrew DC injector in a Hammond box from a previous homebrew project too.

I am very much looking forward to some low band experiments with this setup in the winter. Listening on the LF bands at the moment and hearing the non-stop stream of static crashes reminds me that summer is the time to focus on optimising my LF setup ready for the winter.

73 Matthew M5EVT.

--
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 herme...@googlegroups.com.

[Steve Haynal]

Hi Alan and Matthew,

I am almost done with the synchronizing resets for two coherent HL2s. I found a bug with the "Reset All" so will fix that this week before releasing. You can see what I am expecting with updates to the protocol wiki page for address 0x39 as well as this new wiki section:

https://github.com/softerhardware/Hermes-Lite2/wiki/External-Clocks#gateware-rx-synchronization

It would be great if you could add these resets to your software. I am open to changing and/or refining these resets as we learn more.

73,

Steve

kf7o

[Steve Haynal]

Hi Group,

Just a quick update to share that I am still slowly but surely working on synchronizing 2 HL2s for TX and RX beamforming. I have given up on maintaining two network connections as there were just too many places for samples to become out of sync, especially when thinking about TX. I am working on Verilog that allows 2 HL2s to synchronize with little outside intervention and all send data through one ethernet port. This is a bit challenging because at the beginning each radio has a slightly different clock phase and frequency. I have the training and transfer of commands, TX samples and RX samples working in simulation. The encoding I am using should allow for RX receiver data to be transferred at a realized bandwidth of ~125Mbs. This means we could transfer data for up to 6 384kHz receivers from the slave to the master. Since one radio may not be connected to ethernet, I have moved all the clock configuration sequences into the RTL. Now software can write one bit to enable the external clock. Once the radios are synchronized, all commands are mirrored and synchronized on both radios. This means that sending a change frequency to receiver 1 will send that to both radios as if they were locked. There will be another port open, or some bits in the UDP 0x7F 0x7F 0x7F to specify that a command should only be sent to one radio. This will allow some radios to be synchronized but others to be used individually. From an implementation point of view, this command mirroring is the easiest and cleanest to implement.

I use a hacked version of Quisk which exposes a command prompt to test everything. I'm quite happy with this methodology. I am thinking about making this a small standalone Python library that allows a user to send only commands via another port to the HL2. This can work with existing software to enable new features and provide a code example that can eventually be adopted in software. Nothing new or extra will be possible through this port. It will just support the sending of standard HL2 commands. Some uses would be to configure external clocks, synchronize radios, or change the TX buffer latency. People would install Python and this library, and then there would be a wiki page of short one or two lines to enter to enable different specialized features. No GUI, just a very simple Python prompt for text entry.

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

this sounds like a good way to go and eliminates a lot of the possible issues (and software effort :) ) with multiple network connections and makes tx sound a lot more possible.  I'd made some progress on the other approach but this won't be wasted as I've made some steps towards combining multiple radios into virtual 'super radios'.

With David here https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/sparksdr/zCPYaqpSyvE we are looking at adding a websocket interface into Spark to allow all sorts of things, perhaps I could make it flexible enough to allow the same commands used in your Python script to be sent.

73 Alan M0NNB

[J P Watters]

Currently I have a pair of Hermes Lite 2.0 build 9 radios, that I
thought would allow experimentation with phased reception and possibly
beam forming transmission.

From what I read is that Coherent mode is a receive only configuration
with a special version of gateware loaded.
I also read between the lines that the coherent development is primary
done on the windows platform, so I should abandon my Macbook Pro. for
Ham Radio with the HL2.

With a pair of HL2 loaded with the Coherent Gateware, how does
transmit work? A third HL2?

So many questions, a lot to learn.

..jpw J P Watters
KC9KKO

> --
> 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/88fcedd2-ed7b-4fe8-986f-a909ee1e5bf0o%40googlegroups.com.

[Steve Haynal]

Hi JP,

I actually do most of my development on Linux. The Python module I plan to release should allow for beam forming setup on Linux, Windows or MacOS. I would like to experiment with TX beam forming too. This would use the same 2 HL2s. Once synchronized, they should be able to beam form for RX and TX. There is still quite a bit of development remaining.

73,

Steve

kf7o

> To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite+unsubscribe@googlegroups.com.

[J P Watters]

Steve,

Excellent. That is what makes Python a good interoperable development
language. Now to fix my Apple MACOSX Catalina Python installation.

I would agree that once synchronized, it becomes a math problem to
calculate the timing differential to adjust the phasing of the
antenna's to "point" the TX in a particular direction.
For the longest time I could not envision how "phased antenna's"
actually worked.
To me, it appears that it works like blinders on a horse, where the
direction that "phased antenna's" are pointed is the only signal that
is not canceled by the introduction of opposing phased signals. This
cancelation results in basically reducing the noise floor so that the
signals left, not canceled, are the only only signals left making them
easier to hear. ie improving the signal to noise ratio. What I do not
yet understand is if there is a further additive effect with the
combination of the resulting signals.

This theoretical concept might be more apparent with the
implementation of a pair of "Tiny SA's" that I just ordered from
Eric's project. http://www.carnut.info/tinySA/tinySA.html#BOM My order
was place last week so we will see how long it takes to deliver them.
Until someone explains it differently, That is how I perceive
reception using phased antennas.

Like seeing a mountain range in the distance and actually hiking
across them, Coding is similar to hiking, often underestimated as to
how much or how long it will take. And others will not consider the
physical and mental cost of the journey, often reducing it to the
moment it takes for the memory of the journey.

..jpw J P Watters
KC9KKO

Morris, IL 60450

>> > 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/88fcedd2-ed7b-4fe8-986f-a909ee1e5bf0o%40googlegroups.com.
>

> --
> 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/0cc1502c-9187-4b34-906b-90dc82d80302o%40googlegroups.com.

[Matthew]

Hi Steve,

This all sounds good. I'm looking to tidy up my linHPSDR branch with the diversity experiments. Do you think this HL2 implementation will behave in the same manner as other HPSDR radio in terms of the protocol? E.g. select which HL2 is used in each RX slot based on the ADC selection C&C bits? (This is how I did it in my test application).

73 Matthew M5EVT.

[Steve Haynal]

Hi Matthew,

Yes, I think I should and will try to support that enough for base compatibility with standard openhpsdr software. There may be some additions or small changes.

73,

Steve

kf7o

[Steve Haynal]

Hi Group,

I found some time to work on synchronizing two Hermes-Lites this weekend. The command synchronization which was working in simulation is now working on real hardware. I can connect two HL2s together, have only one "master" connected to the network, issue a command to the master and both HL2s synchronize. Then every command I send to the master is also sent to the slave with precise synchronization.

I started thinking about the receive data now and would appreciate feedback on good directions to go with software in mind. What we are doing with the HL2 is a bit different from the original openhpsdr hardware. The openhpsdr hardware had just one FPGA so the number of receivers was fixed. With that in mind, it made sense to just have switches to say which ADC connects to which receiver, and then to force common clocks to all ADC. But with two HL2s, we have twice the FPGA resources so can have twice the number of receivers.

All I found in the protocol 1 documentation regarding synchronized receivers (diversity) was address 0x00 bit[7] to force a common mercury frequency, addresses 0x0a and 0x0b with attenuator settings for 3 ADCs, and address 0x0e with ADC assignment per receiver. Am I missing anything? I tried SparkSDR but the ADCs selection was greyed out due to my use of a HL2.

What I'd like to do is not have many commands or registers for multiple ADCs. Instead, I'd like to use the third 0x7f in the preamble as a mask that says to which radio a command applies. For example, for the default 0x7f with bits[1:0] set to 11, a command applies to both radios. But if bits[1:0] are 01, then it only applies to the master, and 10 only applies to the slave. This way software has full control over splitting or combining functionality. LNA can be set for one but not the other, and so on. With this scheme there would be a receiver 0 in both the master and slave. This wouldn't work with existing software unless we do something a little more complex with the receiver addressing, essentially remap receivers to different values/destinations in the gateware.

Sending RX data back to the PC is a little trickier as there are not potentially 2X the number of receivers. The easiest would be to interleave the data, so RX0 from master, RX0 from slave, RX1 from master, RX1 from slave, and so on. This might be able to look like a standard openhpsdr radio with odd receivers set to ADC1 and even receivers set to ADC0.

Another option would be to just make the gateware more complex and try to mimic protocol1 exactly.

73,

Steve

kf7o

[Matthew]

Hi Steve,

Good to read the progress.

hpsdrsim emulating orion2 (hpsdrsim -DEVICE_ORION2 -diversity) should allow you to use the features of SparkSDR a little more. You should be able to easily null out the simulated noise. I updated my linHPSDR fork with a clean up of my diversity code. To activate, click "DIV" button on the receiver display window, then to adjust phase etc. this is done in the configuration tab "DMIX#".

Most of my knowledge of openhpsdr diversity comes from reverse engineering open source software, so I am far from an expert. I think I have conclude the same as you regarding command and control. My understanding is that both piHPSDR and PowerSDR are constrained to RX0 and RX1 for diversity reception (please someone correct me if this is wrong). For linHPSDR I coded it such that it isn't constrained to RX0 and RX1. For example, if RX3 is being used, clicking DIV will add RX4 as "hidden" diversity receiver (by diversity mixing RX3 and RX4). This means that for a stock HL2 with 4 receivers, we can have 2 independent "diversity radios". I'm not aware of other software behaving like this. I coded linHPSDR to maintain the same VFO frequencies across the 2 receivers. Alan pointed out address 0x00 bit[7] (common mercury frequency) negates this need (in software) with standard openhpsdr radios (but constrained to locking RX0 and RX1?). However, I still needed this software vfo sync for my hl2cluster experiments.

To answer your question regarding approach - I don't feel too strongly about it but my preference would be to remain compatible with protocol1 to allow best software coverage. However, I'm not sure if PowerSDR detecting an HL2 will even allow the user to have all the diversity options without modifications to the PowerSDR source?

It does seem wasteful of (potentially) half the receivers, and doesn't allow flexibility for independent C&C to each HL2. For my experiments I did on the air with my x2 HL2s setup, I found no need for independent C&C e.g. independent LNA gain. For noise cancelling turning up the gain on 1 rx may be useful to achieve good cancellation?

73 Matthew M5EVT.

On Tuesday, 15 September 2020 05:27:04 UTC+1, Steve Haynal wrote:

Hi Group,

[Steve Haynal]

Hi Matthew,

Thanks for the feedback. I'm leaning towards always interleaving the receivers, with radio 1 having odd receivers and radio 2 even. When in linked mode, the number of receivers will be doubled up to 8. By default, pairs of receivers will be linked such that setting the frequency of either receiver will affect both. I think this should be compatible with one way to setup diversity with protocol 1. If software really wants to "unlink" two receivers, they can send the frequency change with a different 0x7f mask. I'll try it out and see how it goes.

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

this all sounds good. I don't see much point in trying to mimic protocol 1 exactly as it feels a bit incomplete to me. It does allow selecting adc per rx but our hardware does not really have that option and the  0x00 bit[7]  only seems to sync 2 receivers as you say so existing software won't make full use of the radio.  Spark has a layer that shares/tunes/allocates real receivers to virtual ones, I don't see a problem making that work with your suggested scheme. It allows setting phase/amplitude on a per virtual receiver basis and if you don't want diversity you effectively get an antenna switch. Have you any plans for the wideband packet? if that is tricky an adc peak per adc might be useful.

73 Alan M0NNB

[Steve Haynal]

Hi Alan,

Thanks for the feedback. I haven't thought about the wideband packet yet. I'll reevaluate once I have 4 receivers worth of data going across the link.

73,

Steve

kf7o

[Steve Haynal]

Hi Group,

I can synchronize two HL2s with the second unit sending receive data to the master for only a single network connection. There are still a few loose ends I want to take care of before releasing a testing gateware. The basic usage is to initialize a synchronized pair of radios by using the hermeslite.py library or enhanced software. This requires some special commands. Once the radios are synchronized, you can then operate as if it were 2 ADCs synchronized with openhpsdr protocol 1 but with a fixed interleaved pattern or RX1=Master ADC, RX2=Slave ADC, RX3=Master ADC, etc. I've updated the wiki protocol and external clocks pages.

To test and calibrate this setup, I'd like to record the IQ data from both synchronized radios for several FT8 15 second windows or WSPR 2 minute windows. These recordings can then be summed and decoded at a later time. Each time I add the two complex IQ streams, I want to rotate one by a small angle. This will result in multiple versions of the same data each with a different "beam" heading. I can then look at the decoded FT8 or WSPR results and see which rotation angles result in the biggest signal improvement for various directions. My ultimate goal is not to have to account for exact antenna locations, feedline lengths, velocity factors, etc, but to empirically determine good settings for an arbitrary antenna setup. Any advice on how to simplify and quickly do this? My rough plan now is to collect HL2 packet data in Python, build a crude SDR that sums the two IQ streams and generates a single audio file output, and then send this to JT9. This will all be done offline.

73,

Steve

kf7o

[Steve Haynal]

Hi Matthew and Group,

I've been playing with LinHPSDR and diversity today. It appears to work. Blocking noise is more pronounced than improving signal strength. It is hard to make good measurements given QSB. Also, when sweeping from -180 to +180 degrees I do not see much change per degree. I start noticing differences maybe every 20-30 degrees. Is that expected? Please confirm my understanding of the LinHPDSR controls shown below:

Also, how do I enable diversity  mode in SparkSDR? The ADC tab is grayed out. Do I need to spoof the ID of an Orion II or is there another way?

* Assuming 1 RX, does selecting DIV on the radio screen start the second RX automatically and enter diversity mode?

* In the drop down, is ADC1 RX1 only, ADC2 RX2 only, and ADC1+ADC2 the only selection that uses 2 receivers?

* Do the coarse and fine angle rotate ADC2/RX2 only?

* Do the coarse and fine gain adjust ADC2/RX2 only?

73,

Steve

kf7o

[Steve Haynal]

Hi Group,

I spoofed an Orion and the second ADC is no longer grayed out in SparkSDR, but there seems to be no effect for various angles/amplitudes. (LinHPSDR does have an effect.) Also, the wireshark data is showing just one RX, not two. The pulldown menu shows nothing. Is there something more I need to do to enable diversity in SparkSDR?

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

I suspect I may have have broken diversity as that drop down above the phase and gain should list the adc,s you want to use. I'll test it with the Orion this evening. I'll also look at enabling it for the HL2 with the assumption the odd receivers are adc1 and even are adc2.

Are those icons above the circle and the x displayed as in you screenshot?

73 Alan M0NNB 

[Matthew]

Hi Steve,

Your observations sound similar to mine with regard to performance. I initially didn't have the fine tune control in linHPSDR, but I quickly found high precision was needed to null out noise, see here.

I want to do more testing this winter with some small active verticals on top band. I received some good advice here, and in some very unscientific tests, I achieved the best results with a vertical and a dipole. Claudio's suggestion of using a signal generator was incredibly useful (I used my miniVNA which has IQ signal outputs) for debugging my software. Real world signals left too much doubt in my mind that I had the core working properly with all the amplitude and phase variation caused by the ionosphere etc.

1 - Yes, exactly as you describe, the 2nd RX is hidden. You should get some info of what is happening behind the scenes in some of the command line output.

2 - Yes, ADC1 = RXA (the receiver name (e.g. RX0, RX1 etc.) will be on the top bar of the RX window), ADC2 = RXB (the next available receiver slot, this rx is hidden from the user and they don't interact with this rx directly). ADC1+ADC2 = diversity mixing both RXs. I used WDSP to do most the work in the code. The functions are explain on page 150 here. The WDSP c functions are here. Note I'm avoiding naming RX1 and RX2 here etc to make it clear that linHPSDR doesn't have to only use RX1 and RX2 (like RX4 *has* to be used for PureSignal).

3/4 - At the moment I *think* I have it coded such that the "reference receiver" is RXA (this will probably be configurable for the user in a future build) and the rotation/gain is applied to RXB.

Have you got the synchronisation to a point that you can turn off the HL2, turn back on and still use the same phase setting to null some noise. This will be great if we can achieve this. From my experiments it felt like this would be a big ask, but I know you have done a lot more synchronisation improvements since I last played with this setup.

73 Matthew M5EVT.

[Alan Hopper]

Hi Steve,

the last linux version did have the dropdown broken in diversity, there is a test version here http://www.ihopper.org/radio/download.aspx?file=SparkSDR2_0_3-0.linux-x64.deb that should work but it is not a stable build. Both the 2.0.2.9 and 2.0.3.0 windows builds should work.

73 Alan M0NNB

[Steve Haynal]

Hi Alan,

I was using Linux 2.0.2.7. I couldn't find Linux 2.0.2.9. The .deb link gives a 404 error.

Yes, the icons look like what is seen in the picture. If you mouse over the icons or move the screen, they might change and look more as expected.

73,

Steve

kf7o

[Steve Haynal]

Hi Matthew and Group,

I did connect a third HL2 as a signal generator and I am able to dramatically null the signal, although not completely, but I think that is because the signal is still quite strong even with a 30dB attenuator. The LNA adjustment didn't work as I expected for a full -31 dB attenuation and doesn't appear to have the full 60dB range of the HL2, but I'm probably missing something about LinHPSDR. I restarted the radios 5 times and every time the null was at -180 degrees. It was important to also reset all DSP pipelines synchronously in both radios. I did notice that there was a small discrete variation. Sometimes the null was at phase -180 -0.65 and amplitude 0 +0.05 and other times it was at phase -180 +0.65 and amplitude 0 -0.05. It was always one of those two settings. I suspect there is an ADC calibration routine in the AD9866 at power on that makes a slightly different choice at times. I did move off frequency by several 100 kHz and back, and the null was maintained. In fact, the signal stayed null across the several 100 kHz I tried too, both when changing the RX frequency or the signal generator frequency. No reset is required when changing the frequency as both NCOs can be fully and synchronously locked now. Sometimes a small adjustment to the fine phase was required, but it was always pretty close. I made the amplitude and phase fine resolution even finer, but that amounted to little improvement.

When looking at on the air signals, I don't see nearly the dramatic effects as with the signal generator. I do see noticeable differences though when listening to WWV or FT8 signals. I found a setting that felt like it was giving me more 40M FT8 spots and let it run overnight with better than average results after a very nonrigorous and purely qualitative analysis. I am working on a better metric where I record IQ data for several 15 second windows of FT8 and then post process the data with JT9 to see which rotations are best for which directions. I added a control bit to turn off the watchdog timer to make this easier. I will share results once I have some.

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

something odd is happening with my server, try http://www.ihopper.org/radio/download.aspx?file=SparkSDR.2.0.3-0.linux-x64.deb.gz and remove the .gz . There was not a 2.0.2.9 for linux as that build was not reliable on linux. What distro gives the odd icons?

73 Alan M0NNB

[Alan Hopper]

Hi Steve,

I sorted the server and fixed a bug so  http://www.ihopper.org/radio/download.aspx?file=SparkSDR.2.0.3-1.linux-x64.deb  is the latest. If diversity does work for you in spark, you can load multiple ft8 virtual receivers on the same frequency and set different phase for each. This will probably only work with one frequency and from a clean start to ensure the correct receivers are used. It may not work as at all as it relies on a bit of luck that the receivers are in the correct order to match the orion.

73 Alan M0NNB

[Matthew]

This sounds great Steve. The repeatability sounds good enough for more general direction beam steering (E-W/N-S), and I imagine for QRM elimination, QRM probably shifts about in phase/amplitude enough that regular adjustment would be needed anyway.

73

Matthew M5EVT.

On Tuesday, 6 October 2020 06:24:31 UTC+1, Steve Haynal wrote:

Hi Matthew and Group,

[Steve Haynal]

Hi Matthew and Group,

I have the code written which collects and saves 15 second FT8 windows of IQ data. I'm taking a close look at NR0V's wdsp library, used in at least LinHPDSR and piHPDSR, to do the demod and filtering. That is quite the impressive package and a gift to opensource. I think I should be able to use Python cffi (I've wanted to learn about that) for a quick and easy interface to Python and have everything I need. The most recent wdsp documentation I could find is here.

73,

Steve

kf7o

[Matthew]

This sounds like a really interesting little project. Yes, I agree that wdsp is a fantastic open source library. Something that never makes it up my todo list is to look at modifying wdsp to experiment with OpenMP. There are a lot of for loops within the library that might benefit from "parallel for" implementations - particularly for low power processors that are multi-core? However, my general experience with this sort of hypothesis is you just have to try it to see - theory doesn't always match up.

I'm not very familiar with cffi, but in the past I have used cython and experimented with PyPy. I look forward to your results with this. This suggests that it can't match cython for performance, but perhaps you won't hit this as a limitation if you stick with low sample rates and 2 receivers?

73 Matthew M5EVT.

On Friday, 9 October 2020 06:10:58 UTC+1, Steve Haynal wrote:

Hi Matthew and Group,

[Steve Haynal]

Hi Matthew and Group,

I have been having fun playing around with my FT-8 analysis software. I find that I can spot 5%-30% more stations in the same 15 second window if I decode for RX1+RX2 where RX2 complex IQ data is rotated by various angles. The baseline number of spots is all unique spots from RX1 and RX2 when each receiver is decoded individually. For example, in the 40M data I am just looking at now, there are 17 spots for RX1 and 18 spots for RX2. 3 of the RX2 spots were not seen by RX1, so there are 20 unique spots total for RX1 and RX2 alone. When I then decode the data 16 more times, each time with RX2 rotated by an additional 22.5 degrees, there are an additional 5 unique spots for a grand total of 25 spots, 20% more. The sensitivity to the rotation angle is quite broad. For example, on 40M TI2HAS was 2dB stronger for RX2 rotation from 180 to 247.5 degrees. In general, there are rotations which improve reports by 2dB-5dB. Sometimes one of these angles improves a signal enough to decode and this is what adds another unique spot to the total. I have seen similar results on 20M and 40M. My two antennas are an attic dipole and a long wire which is perpendicular to the dipole. Due to space limitations, the long wire actually passes a few feet above the middle of the dipole at about mid point of the long wire. This is essentially simultaneous beamforming in multiple directions.

I am working on a nice way to present this data. Hopefully I can post some tables tomorrow. Also, I am a bit reluctant to release the gateware as there are still one or two bugs rattling around which I know how to deal with but should fix before general use. Let me know if you really really want to try this experimental gateware.

I am using wdsp with cffi. Python with numpy hasn't been the performance bottleneck as it is really just gluing things together. By far the most time is taken with running JT9 at depth 3 for all the various rotations. Second is wdsp. All my processing is offline with recorded IQ data, no realtime RX, so no real pressure for performance. 

According to the wdsp documentation, the last parameter of OpenChannel (int bfo) can be nonzero if you want calls to fexchange to block until data is ready. This is what I want but it hangs on calls to fexchange if bfo is 1. LinHPSDR sets this to 0. I've also been setting this to 0 with a sleep of 2ms to ensure the data is ready and there are no errors. Does anyone know how to properly use the blocking feature?

I've also downloaded, modified and compiled Pavel's FT-8 decoder. This is interesting as it takes 4kHz complex IQ data. I have 48kHz IQ data from the HL2 in Python and can easily run that through a simple scipy LPF and decimate. This may be faster overall.

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

this sounds great, I've also decoded extra spots by running multiple virtual receivers with different phase on the Orion.  Making this work over many bands and modes is an interesting challenge from a cpu use perspective.   I've always believed Parvels approach is a bit faster as the decimation is effectively free due the radio software doing the filtering anyway.  I wonder if the phasing could be done even later in the chain, maybe after the first fft in ft8 to save some more cpu.

73 Alan M0NNB

[Steve Haynal]

Hi Group,

I'm creating "heatmap" tables to help me understand how to use two coherent receivers. See the two attached pdf documents for 40m and 20m data. This shows the signal report for each station on RX1, RX2 and additions of RX1 and RX2 when RX2 is rotated by the indicated angle. An empty entry means the station was not reported for that setting. A numerical entry with white background means the station was reported for that setting but the signal strength was not above the best or below the worst report from RX1 or RX2 alone. Reports with green indicate that the signal strength exceeded either RX1 or RX2 alone. The more intense the green, the more it exceeded. Reports with red indicate the signal strength was less than either RX1 or RX2 alone. Again, the intensity indicates by how much. Reports with blue indicate that this report only shows for some combination of RX1 and RX2, not RX1 or RX2 alone. Again, the intensity indicates the best report. There are spot totals in the bottom row as well as global total spots in the top table title.

So far this data looks best for 40M. For 20M, there were many JA stations, but one of my antennas does not do well in that direction and it showed in the data. There are settings for both 40M and 20M which improve reception towards my east, the rest of USA.

73,

Steve

kf7o

[Matthew]

Hi Steve,

Very interesting looking through these tables. The beauty (and also the problem!) with offline data like these is that you can just keep processing it over and over! I was a little surprised that the South American stations you spot on 40m were stronger at around 90-120 deg. In fact a lot of signals are strongest here. I wonder if you are nulling out a local noise source in this direction? Or perhaps the "beam heading" and phase angle can't be thought of in the same way with antennas that are polarised differently?

73 Matthew M5EVT.

[Steve Haynal]

Hi Matthew,

I collected some more 40M data this morning when the band is open to stations around the Pacific rim. I saw the same pattern with the strongest/most reports at ~120 degrees. So I agree with you that this is probably some sort of local noise nulling and not beamforming. This makes sense as my two antennas are probably too close together for good direction distinction with 40M wavelengths. But it is nice to know that I can dial in ~120 degress to linHPSDR or SparkSDR when operating 40M and expect 10% to 20% more spots!

I don't have a good explanation for 20M behavior and why I can block JA but not improve JA with coherent receivers. I plan to collect some more 20M data tomorrow morning when the band is open to Europe and see what that looks like.    

73,

Steve

kf7o

[Steve Haynal]

Hi Group,

I did collect data on 20M when it was open to Europe and there are some interesting patterns in the data. Attached is just one heat map which illustrates this. First, notice that DX stations to my North East can generally be improved with two receivers. See 5T5PA, MI0NWA, HA1RB, EA1CP and HA1AD. But notice the stations that are probably one hop from me or line of sight, KJ7BRE, W2GLD,  KE8PBM and N0YO. Even though these stations were relatively strong, they were only seen on one of my antennas. Perhaps after one hop there is still significant signal polarization and my two antennas are oppositely polarized for 20M? The red for these stations show that there really is no helpful component from the other antenna, either to improve the signal or reduce noise. That is surprising and I don't have a good explanation. Finally, notice YB6RMT from Indonesia which only shows up for one combination of RX1 and RX2 and at a relatively strong -4. I've verified that this is a legitimate spot. I've seen this type of surprise spot several times in the broader data.

73,

Steve

kf7o

[ron.ni...@gmail.com]

Hi Steve,

I now have two HL2's set up with two different antenna's (one 20M vertical, one horizontal loop-on-ground).

Is there a summary somewhere of the cabling, gateware versions, network and software requirements needed to run some diversity experiments?  Do I run 1 or 2 Metis Protocol 1 UDP stacks?  On 1 or 2 servers (I currently use 2 Raspberry Pi 4's on the same LAN)?  Do I need any other special hardware, such as a GPS disciplined clock oscillator?

Thanks & 73,

Ron

n6ywu

[Steve Haynal]

Hi Ron,

Please see this post  and this wiki page for HL2 connection details. Some of the configuration material is dated but the required physical connections remain the same. You run 1 protocol 1 UDP stack. The pairs of receivers can be synchronized. For example RX1 from radio1 is synchronized with RX2 from radio2, even though the RX2 samples are sent via ethernet from only radio1. No GPS clock is used. One HL2 becomes the master and its clock is used for the second HL2. I have experimental unreleased gateware. I need to fix a few bugs and then I will release it.

73,

Steve

kf7o

[Steve Haynal]

Hi Group,

I did work on this again over the holidays. For those new to this thread, I have two Hermes-Lite 2.0's connected to two antennas but sharing a single clock. Since the radios are in lock step due to the single clock, the two receive IQ streams are phase coherent. This means I can multiply one stream by a complex constant (angle of rotation) and add the two streams to do beamforming at HF, just like many modern home wifi routers now do at 5GHz. Sometimes this is called diversity reception. It can be used to help cancel noise or improve reception from specific beam headings. Hams have been building similar phased array antennas for years, but the beauty of SDR is that you don't have to carefully measure coax lengths, position antennas, and build specialized analog gear. Instead, you can delay signals and adjust phases mathematically in software. You can make these changes on the fly. And most interesting to me, you can take the two IQ streams and process them differently in parallel, thus creating multiple simultaneous "virtual" beam heading IQ streams.

Although I am sure better results could be achieved by more thought out placement of two good antennas, I live in a community with an HOA and antenna restrictions. I have a 30M attic dipole and a 20M long stealth random length wire antenna along the peak of my roof. I am making FT8 reception experiments with these two antennas to determine the best settings for different directions and bands. For better or worse, I think working with antenna restrictions like I have is more representative of what hams, and especially younger hams, will face now and in the future.

I have changed my experimental setup. Before I was using wdsp to demodulate 48kHz IQ into USB audio which was then sent to WSJT-X to decode. I was doing this for 16 different rotations (evenly spaced around the unit circle) to create 16 different streams plus the original RX0 and RX1 streams. I couldn't run this in real time so would capture 15 seconds of data and then spend more time than that processing it. I created heatmaps posted earlier in this thread that did show 15%-30% more FT8 spots could be achieved with beamforming and there was some directional sensitivity to the different rotations.

Now I have switched to Pavel's ft8d decoder optimized to run on ARM processors. This removes the wdsp step as ft8d accepts raw IQ samples. I created a special 5-RX HL2 gateware variant that generates IQ at narrow 4kHz, the rate expected by ft8d. I run ft8d at depth 3 which requires more computational time but can produce more spots. I wrapped the ft8d Fortran code for use with Python using f2py. This allows me to create easy-to-use and always-available decode threads which avoid the overheads of starting ft8d for each decode window. I also used PyZMQ to create a distributed compute cluster. I setup all 3 of my Raspberry Pis (3B, 3B+, 4), an old atom-based Liva PC, an old macbook pro plus both of my newer Zen PCs in a compute cluster where every processor in every computer is used in parallel. With this, I can decode 80+ very active 15 second FT8 IQ streams at depth 3 in real time. (FT8 decode is an interesting benchmark. Decoding the same data set of 4 15 second windows takes 26 seconds on a RPi 3B, the slowest, down to 2.4s on a Ryzen 5 2400G, the fastest.)

I run this setup for 24 hours and bin spots based in their heading and IQ mix. I count total spots (not unique stations) and break ties with higher total SNR (convert SNR to positive values only and then add up SNR for all spots). This is providing some clearer results. For example, on 40M I see an advantage when rotating RX1 by 283 degrees for stations from Europe, which are at azimuthal headings of 20 to 40 degress at my QTH. 1333 total spots versus 1239 for RX0 alone and 983 for RX1 alone. It is also reassuring to see that the next highest bins were at the other two rotation angles nearest 283 degrees which I used. I do not see uniform patterns in all directions. For example, for a wide range of headings to my west, 230 to 340, rotating RX1 by 180 degrees works best. The antennas are close together, interact in various ways, have different radiation patterns, and are subjected to various noise sources, all of which creates a very complex system which I think can best be characterized through empirical measurements.

All the code to do this is in github. It is not ready or meant for general use, but if someone is comfortable with Python and interested in trying this, I am willing to help get them going.

[J P Watters]

Steve,

So COOL!!!

I have been under the weather for a few weeks, but reading this makes me feel better. 

And it means that I have to get busy and get a second antenna up and tuned.

I have a pair of HL2 B9 transceivers, and will have to "bond" them together when I get the second wire in the air.

My first question is, how many raspberry Pi 4's would it take to make a cluster to do real time processing?

ie https://www.picocluster.com/collections/raspberry-pi4/products/pico-5-raspberry-pi4-8gb

What is the software of choice to operate with? Quisk, Thetis, OpenHPSDR

Currently I use a Macbook Pro (Mid 2015) I7 processor, MacOS Catalina with Spark and OpenHPSDR. Do I need to change platforms?

..jpw J P Watters

KC9KKO

Morris, IL USA

--
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/88fd9c80-9be1-4a64-b8f0-f511e56d915fn%40googlegroups.com.

[Matthew]

Steve,

Funny, I just re-setup my HL2s yesterday evening for some coherent RX experiments. My focus is on improving the RX antenna system. I have a range of homebrew RX antennas I've built in the past that I want to try in this system; mag loops, LoG, active whips, hi Z etc. At the moment I have too much gain difference between antennas so I need to tweak linHPSDR to set LNA gain per RX/ADC. Hopefully more on this over the weekend.

I completely agree regarding modern antennas and the realities of what can be installed. Furthermore, there is just so much noise in an urban environment. These practicalities are exactly what I want to explore in my experiments. My hypothesis is that an EFHW (good urban stealth TX antenna), rx loop and a noise antenna with x2 HL2 should provide a good system for such environments.

Thanks for sharing your experiments, I would like to repeat these in the coming weeks.

Jpw,

I think OpenHPSDR might work. SparkSDR doesn't work at the moment, but I think Alan can very easily make it work? My fork of linHPSDR works with coherent HL2 RX, not sure how comfortable you are with linux (this should work on rpi, I'm happy to help anyone who wants to experiment but isn't sure what they are doing with linHPSDR)?

73

Matthew M5EVT.

[Steve Haynal]

Hi Matthew and JP,

Great to hear you are experimenting. I have an old mag loop I need to dust off and try again too. For a birthday gift, my wife is hiring a professional handyman with roof experience to come over and string up a bunch of stealth antennas as the roof pitch is little too steep for me. I think I can have 3 end fed random length wires: the one down the center peak now, and then two on each side of the house. One problem I suspect I have is that the current random length wire is a length that when I tune it, the most sensitive portion of the antenna is very near my electronics on 30M and picks up noise. I'll have to have a variety of lengths. I also considering building/buying several N7DDC autotuners and powering over coax for some doublets in the house eves. Any suggestions on a good variety of stealth antennas is appreciated.

Regarding the Raspberry Pi 4s, I mainly added them to my cluster as once a cluster was setup it was easy to add computers so I threw everything I had at it to see how they performed. The picture you posted looks very clean. My cluster looks more like a jumble of power and ethernet cables. I send 16 FT8 decode jobs per band I am monitoring to a single computer as I do not want to send the sample data for the same band many times. I found that the RPi4 is not enough to handle a 16 decode job every 15 seconds. It would not complete in under 15 seconds when a band was busy, open and most active. This is maybe one or two hours a day. When the band is closed or just has a few stations active, it will complete in less than a second. I compiled ft8d with the best optimization flags for each CPU.

If you want the most bang for your buck, try atomic pis, used thin clients (check for good CPU passmark scores) or chromebooks/laptops with busted screens. One of my best performers is a 10 year old macbook pro with a busted screen that has been sitting idle in my closet for years. I installed ubuntu server on it and it is almost as good as my Ryzen systems. I've included some performance data I've collected. These are running the same 5 saved 4-decode jobs on all systems. In this case, a decode job is 4 separate 15-second FT8 decode jobs run on a single processor. In practice I divide the workload among all available processors. For example, you can see that a 4-decode job on the RPi4 takes around 10 seconds on a single processor. When you scale this up to using all 4 CPUs, then you are around 12-13 seconds for a 16-decode job as parallelizing is rarely perfectly linear. When the band is very busy, this is pushed above 15 seconds. I've also included the CPU passmark score as well as core and thread count in parenthesis.

73,

Steve

kf7o

***Potential Thin Clients:

AMD G-T48E (416 2C/2T)

AMD G-T56N (454 2C2T)

AMD GX-217GA (743 2C2T)

AMD GX-415GA (1363 4C/4T)

AMD GX-420GI (1573 4C/4T)

***Old Chromebooks and other Intel Atom CPUs:

Intel N2807 (461 2C/2T)

1 10.3s

2  9.8s

3  9.0s

4  9.2s

5  8.0s

Intel Celeron 2955U (745 2C/2T)

Atomic Pi: Intel Atom x5-Z8350 (921 4C/4T)

Intel J2900 (1126 4C/4T)

1 8.2s

2 7.9s

3 7.2s

4 7.4s

5 6.4s

Intel N3350 (1156 2C/2T)

1 7.3s

2 7.0s

3 6.4s

4 6.6s

5 6.0s

***Old Macbook pro

Intel i7-2860QM CPU @ 2.50GHz Sandybridge (4517 4C/8T)

1 3.2s

2 3.0s

3 2.8s

4 2.8s

5 2.4s

*** AMD Ryzen

Ryzen 3 3200G (7239 4C/4T)

1  2.7s

2  2.6s

3  2.3s

4  2.4s

5  2.1s

Ryzen 5 2400G (8731 4C/8T)

1  2.4s

2  2.3s

3  2.1s

4  2.2s

5  1.9s

***Raspberry Pi

RPi 3B 4C

1 26.0s

2 24.5s

3 22.3s

4 22.9s

5 20.2s

RPi 3B+ 4C

1 22.3s

2 21.6s

3 19.5s

4 20.2s

5 17.5s

RPi 4

1 10.9s

2 11.9s

3  9.4s

4  9.6s

5  8.5s

[J P Watters]

Steve,.

I think I have parts for building a pair of 300 watt amplifiers based on the Motorola MRF141G.

Upsizing a LPF/BPF to combat potential harmonics. Maybe it should use the same control scheme as N2ADR.

I have yet to figure out how to tweek the N7DDC Autotuners to handle 300-500 watt power. I can't get the idea of latching relays out of my brain, but I need to get over that. I saw that HobbyPCB has a new of a 500W autotuner, https://sites.google.com/site/hobbypcbhardrock500/home/atu-500-antenna-tuner, it doesn't have a standalone controller, so that becomes another project. Maybe a combination of the two.

I am going to start with 5 RPi4 8gb with 32gb MicroSD cards. I think I will use the case and power supply from the PicoCluster Gang and

there are 3 or 4 RPi4's here to build with. https://www.picocluster.com/collections/pico-5/products/pico-5-raspberry-pi4-8gb 

That should create less spaghetti. 

We will see how that works to start with, easily adding more RPi's as needed.

I think that this is the final nudge to start doing more with command line processing. 

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/69bb2b2a-58b7-40ef-a84f-489f42d2e707n%40googlegroups.com.

[Ulf Tjerneld]

>>For a birthday gift, my wife is hiring a professional handyman with roof experience to come over and string up a bunch of stealth antennas as the roof pitch is little too steep for me.

>>73,

>>Steve

>>kf7o

 

True love <3 😊

 

 

   

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/88fd9c80-9be1-4a64-b8f0-f511e56d915fn%40googlegroups.com.

--
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/69bb2b2a-58b7-40ef-a84f-489f42d2e707n%40googlegroups.com.

 

[James Ahlstrom]

Hello Steve,

These experiments are very interesting. I see you are using Python. Although I don't know how you re-synchronize the two sample streams, I wonder if the Python sample interfaces in Quisk might be of use. If you want, I would be willing to modify Quisk to support your work.

Jim

N2ADR

[Alan Hopper]

Hi Matthew and all,

yep making spark fully support this is on the list. The basics are already there and might just work anyway if the external program is used to set up the hl2s and if you make the gateware report as an orion, this would probably rely on a clean start and a bit of luck for the correct receivers to be allocated.  You can set a separate gain and phase for each virtual receiver so experiments similar to Steve's are possible, the psk reporting will cope if you tume multiple receivers to the same mode and band but with different gain and phase.  I shall shortly release a version that allows many instances of spark to connect to another and share gateware receivers, this would allow spreading the processing load.

I've grouped this job together with trying to use the HL2 clock for my transverter as they involve similar things.  I have some websocket stuff to finish first and support for the new wsjtx modes.

73 Alan M0NNB

[Matthew]

Hi Steve,

I have had some reasonable success today with an End Fed Half Wave and my LoG. I can null stations and make them louder compared with listening only on 1 RX. It is also interesting to listen to RX1 in left ear and RX2 in right ear and hear the signals pan left to right and back. It is also very satisfying to null out local noise sources.

I don't think I fully understand the frequency synchronisation/direction of commands. I enable sync with hermeslite.py. For now, when I have the WDSP diversity mixer enabled I am only sending commands to RX1 by sending 0x7d in the 3rd sync byte before command packets. My understanding was that frequency changes would still be sent to the 2nd HL2 (via the LVDS link). However, my observations on the panadapter suggest this is not the case? It would be great if it could do this without needing to direct a command to the 2nd HL2 for the new frequency. When I develop some more confidence and start transmitting through the primary HL2, I really want to send commands to the 2nd HL2 by exception so that I don't accidentally TX into my RX antenna preamp.

Regarding stealth antennas... If at all possible try to get things on mini pulleys or some method to re-fit them without going back up to the roof. I use this wire https://www.sotabeams.co.uk/antenna-wire-lightweight-100m/ and the brown wire is almost impossible to see in my garden. I use fishing line for rigging, this is also near impossible to spot. The only problem with this small wire is it is not perfectly robust. I have had breaks in storms. Hence, my suggestion to be able to be able to get at the wires moderately easily to repair/change. The more robust/weatherproof you make the wire, the easier it is to see. For random wire antennas, I strongly suggest picking half wave lengths to boost efficiency. There are endless debates about whether this needs a ground/counterpoise or not, but my own experiments by my VNA convinced me that a 1/8 wave counterpoise was worthwhile. I think you have said in the past you only run QRP so you could get away with a smaller 43 mix core for a nice multi-band transformer. Then perhaps you might be able to fit a 30m loop around your roof for WARC bands? Fit this to a 4:1 balun and feed straight into an auto ATU? I have had mixed success (noise/stray RF) with balanced feeder very close to the house.

I will never forget working southern Chile on my attic 20m dipole with 50 W. Granted the Chilean station was doing all the work, but it really showed me that attic dipoles are a good stealth option (and a balun becomes a must at the feedpoint to combat noise).

73 Matthew M5EVT.

[Steve Haynal]

Hi Jim,

The receive data from the HL2 is now synchronized so it at least arrives at software synchronized.  Any additional hooks or pointers to existing hooks in Quisk would be appreciated. Ideally, I'd like a hook in Quisk where I have access to a numpy complex array of all demodulated and decimated receiver IQ data. The array depth could be for several hundreds of milliseconds worth of data at a time. I'd like to be able to say I want 4kHz (or 6kHz or 12kHz) bandwidth USB at this frequency. When multiple receivers are open, I'd like to know which sample from RX0 responds to the same point in your processing chain as a sample from RX1. Maybe this already exists in Quisk and I just haven't learned how to access it.

73,

Steve

kf7o

[Steve Haynal]

Hi Matthew,

Thanks for the antenna advice. I'll have to consider some pulleys. I have been using this wire.

The intent is to have commands sent to both radios when the 3rd sync byte is 0x7f. This would allow default software implementations to work. 0x7d will only send to the first (master) radio, and 0x7e will only send to the secondary radio. This has not been extensively tested so please let me know if you see issues. Also, I need to document this better.

There are a couple of gremlins in the sync functionality that I haven't yet debugged. My setup will work for many hours, but if I turn the light on or off right next to my setup, there is some electrical interference that causes some FSM to hang. The HL2 clocks still appear synchronized, but data is returned at a much slower rate. Also, the AD9866 has a PLL that produces a clock for the FPGA. Most of the time when the input clock for the AD9866 changes frequency this PLL will relock, but a few times it does not and just stops sending a clock to the FPGA. I need a way to force a reset of the AD9866. Currently you have to power cycle both units for either of these problems.

73,

Steve

kf7o

[devon...@gmail.com]

For small pulleys, I use this kind of thing, useful as it will 'split' to allow putting the wire in/out without removing the wire center piece or end insulators etc.

About the size of your thumb.

https://www.ebay.co.uk/itm/113899473407

Use heavy fishing line to haul it up/down and it ought to be pretty stealthy.

73

Nigel

G4ZAL

[Matthew]

Thanks Steve,

I suspect I may have come across some of these gremlins, but at the moment I don't have sufficient confidence in my linHPSDR changes to point fingers elsewhere! I did have to make some trips out to the garden to do physical power cycles to return to normal service. Unfortunately, I was not being methodical enough at the time to be able to repeat it.

My main question I would like to understand is as follows - I have used hermeslite.py to synchronise, I am directing all commands to only the primary HL2 (0x7d). If I change frequency (and never issue command via 0x7e or 0x7f), will the secondary HL2 change to this new frequency via the lock/sync mechanism? I do not see this happening.

73 Matthew M5EVT.

On Saturday, 9 January 2021 at 21:09:42 UTC softerh...@gmail.com wrote:

[J P Watters]

Steve,

First of all, Thank you for what seems to be an endless amount of work keeping the HL2 on the cusp of SDR technology.

In a recent email after you updated us in the group, you indicated that you would like to use a N7DDC Autotuner for the HL2.

I have not found any N7DDC information to support what is needed to tune a 600Watt amplifier. As close to an application note for higher power is a couple of references to simply using relays that support 3A currents, 1KV capacitors and higher wattage resistors will increase the power capacity to several hundred watts. 

With that said, I am planning on building an upsized N7DDC with that in mind. Worst case failure seems to me to be fixing a N7DDC Autotuner after it suffered a overload and possibly replacing the finals in the amplifier. Maybe by then a better power upgrade for the N7DDC autotuner will be available. 

And tidbit of cool news is that next week, we expect a couple of days in the 40's and higher. Likely will be a good day to hoist up a new antenna to swap out my current simple random tuned wire with a new 

Thoughts?

[Steve Haynal]

Hi Matthew,

No. Even though the clocks are locked, you can change radios independently.

0x7f - Commands are replicated and go to both master and secondary radios in synchronous fashion

0x7d - Commands only go to the master radio. These are not sent to the secondary radio.

0x7e - Commands only go to the secondary via the master radio. The master ignores these.

73,

Steve

kf7o

[Steve Haynal]

Hi JP,

I just ordered a N7DDC ATU-100 from Ali Express. I am not sure how well they work. I know for QRP I have to change the firmware so have also ordered  a Pickit 3. See:

https://github.com/Dfinitski/N7DDC-ATU-100-mini-and-extended-boards

I thought there was also some mention of 1500W on that page but didn't look to carefully as I am a QRP guy.

73,

Steve

kf7o

[Steve Haynal]

Hi Matthew,

I really need to write documentation for this, but maybe this will help.

Once the radios are locked, the hermeslite.py will actually report 8 receivers instead of 4 if you are using the main gateware. Receivers 0,2,4,6 are considered from the master radio, the one with ethernet connected. Receivers 1,3,5,7 are from the secondary radio. When using 0x7f, the same command goes to both radios. Frequency changes to either receiver 0 or receiver 1 will affect both receiver 0 and 1. If you want to set something specific for only one radio, for example you want coherent receivers from 0,1 and 2,3 but want to use 4,5,6,7 on independent frequencies, then you use 0x7d or 0x7e to address the specific radio, and use the appropriate receiver index. Another reason you may want to address a specific radio is to change the LNA gain just for that radio.

73,

Steve

kf7o

[devon...@gmail.com]

Steve,

I am currently building an N7DDC EXT ATU (clone Chinese kit) and for QRP use, you do need to change the firmware, but also change the windings on the binocular 'tandem match' from 10 turns to 5 turns.

https://www.youtube.com/watch?v=dPys_-_wPcQ

For the tandem match, I used the centre core from a bit of RG142 rather than RG58 as the conductor fits the PCB holes (whereas RG58 needs some wire strands removing).

73
Nigel

G4ZAL

[Matthew]

Steve,

Thanks for the reply and clarification. I'm currently working on a method to visually confirm the gain of both receivers is matched. If you don't mind sporadic questions (and there is no urgency on replies, I usually only find time at weekends), I'm comfortable with the documentation as it is while we are in these early experiments/trials. Two hopefully quick questions:

1 - I have had a look at the verilog code, but I couldn't figure out; does the MOX bit get sent to both units?

2 - Is the reported ADC clipping and temperature always data from the primary HL2?

I seem to be able to hit a fault condition if:

1 - open linHPSDR, 2 receivers present;

2 - I have issued a sync command via the hermeslite.py function;

3 - I cause linHPSDR to crash or issue a ctrl+c from the command line to kill the process;

4 - Issue desync command from hermeslite.py;

5 - Re-open linHPSDR, add RX2;

6 - issue sync command via python script. I seem to get garbage from RX2.

7 - I have to power cycle both HL2s to restore normal service.

In summary, I think if the radios are synchronised, 2 RX are enabled by C&C protocol commands and the PC software crashes, the HL2 link goes into an odd state that can only be fixed by a power cycle. Do you want me to put an issue on github for these sorts of findings or given the beta state are you happy with them just here?

73 Matthew M5EVT.