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/8f84e621-62c2-4784-8010-2f5b59029ad9n%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/16e8053d-06ce-483e-a503-7ac76189bceen%40googlegroups.com.
Yes to VHF/UHF!
Just FWIW my ELAD DUO transceiver & Q5 Signal transverter handle a local with 112dB SNR. Signals can be very, very strong on VHF so ENOB will be most important. SHF and above you’re usually happy to just see a signal.
In tomorrow’s episode – egg sucking for beginners 😊 .
Simon Brown, G4ELI
Hi Steve,
I probably have more SDR than anyone else, trust me when I say that Lime / Hack / Pluto don’t come remotely close to HL2 in either RX or TX.
Yes, Q5 is expensive but very good and there aren’t a great number of HF SDRs which can drive it – ELAD DUO, ANAN 10 come to mind. A lower cost SDR like HL2 is ideal here.
I agree totally about a modular front end with ADC / DAC, some interesting chips are emerging from China, slow boats permitting.
--
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/f8acd139-9e0d-430d-9f30-8fd08c92899en%40googlegroups.com.
Regarding the I2C through the HL2. I do not see a need to add ‘more’ as we can add devices on the existing bus and use the existing mechanism. I don’t think any proposed uses require great speed? A useful addition could be an i2c line driver chip to make it easy to add things that may be outside the box and help isolate the internal bus for better reliability .
I would avoid using a separate ethernet connected box for simple things that the i2c can handle via the HL2. The HL2 can, will be, and is, used remote and a separate control box on an ethernet requires an ethernet switch or another long cable. These add more RFI exposure, more equipment, space and cost to house, and a small switch likely requires 5 or 9VDC so another odd power supply beyond the control circuit needs. My use case it the HL2, transverters, amps and antenna switches located in a box in the back, attic, or roof of a house, truck, or RV. Today all one needs is a single ethernet to the control point because the i2c and/or serial from the HL2 extend your shack.
Some jumpers to remove RF2 and relay would be nice. For my split IF transverter use I tap RF1 an RF3 on the IO strip but still listen to the relays, I did not want to modify the HL2 board.
Mike
K7MDL EL87sm & CN88sf
--
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/39749b0c-89af-4551-81ea-d53b25c85595n%40googlegroups.com.
The future HL project is complicated by its own versatility and so many people want to use it in so many different ways with the list below touching on some of them.
Use as a stand alone QRP radio for WSPR, SOTA etc.
A driver for any number of peripherals, linear, transverter etc.
A complete QRO radio contained in a single case.
A test instrument and experimental radio.
Each of these use cases places a different demand on the supporting PC consoles, firmware and hardware and puts a big demand in time on the people supporting this, as requests for this property or other rolls in. Mostly the developers want to service these requests as generally it means that their product will get better and better but sometimes it only adds value to the requester and has to be gently refused. The choice of using a (very close) subset of the Hermes protocol has proven to have been a huge asset with PC Console software immediately available and yet more was re-written to accomodate the Hermes-Lite/Hermes and it now has a sustainable user base and should be kept. There has been times where we have stolen function bits from Apollo or Alex filters or the like to support popular peripherals but nothing which destroys compatibility.
Where we go in the future will be driven by the final use of the HL and here is a look at what each of the four nominated cases might bring.
1. This fits with the current HL2 and will appeal to the advanced to not so technical user as it is complete and fairly easy to get going – load a Hermes compatible PC console onto your computer, plug the HL2 into the network, power and antenna and you are good to go. For the portable QRP operator the RaspberryPi and a 7” screen will have you hill topping in very little time. The radio of the future should work with current software and not change the current concept of radio and filter in one box with some external lines and data out/in. Different FPGA’s or LNA’s are “black box” and won’t noticeably alter the performance except perhaps more Rx for WSPR but aerials are usually the constraint there.
2. Here we are appealing to the technically competent to exceptionally talented and providing a base that will drive all the external devices that they love to build, ranging from a Hardrock kit to an aesoteric fully protected max limit amplifier with auto band changing and bells and whistles. These people will be looking for a performance HL which will support undersampling with a grunty FPGA and the best LNA – external attenuators if needs be. A wee bit canny with the cost but not an over riding factor as long as it is high performance and good value for the dollar and maintains backwards compatibility. We don’t want to lose the development investment in the HL2 or diverge off so far that there is the old HL2 group and the new ones who don’t quite match.
3. The dedicated home brewer will be looking at the new HL2 as a board to form the heart of their home brew transceiver. They will tend to the case, filters, amplifiers and control system building up a device that will be the envy of Yaesu Icom et al. The board needs to be a performance board and cost is a secondary consideration. The firmware and good PC console software is what counts. The operator will probably sit in front of this radio in a ham shack and will be able to plug in and turn knobs.
4. The owner of this HL version which is a good match to the “Hermes-Nano” will be looking at a cheap board which runs a decently performing radio, not necessarily in a case. It will need to produce +37 dBm on one output and +17 dBm (ish) on another. Two Rx inputs are required with one being able to be jumpered to an aerial changeover on the 5W output or jumpered to an sma for separate receive port and the other input through an isolating pad, dedicated to pure signal or similar use. Many users of this board will be avid experimenters tinkering with devices like Arduino or RP2040 MCU and a good buffered I2C as posted in here would be an advantage. Bringing as many outputs/inputs to connectors would be an advantage
The following is my personal wish-list. Some features that are already in HL2 are not mentioned but I would not like to see them go as I already use them.
ALC
Facilities
to accept an ALC signal from an amplifier in the range 0 to 3 volts
(or suitable alternatative) and reduce the RF output
proportionately. The amplifier control circuitry is responsible for
setting the control voltage range and any threshold. Maybe an opto
coupler would be appropriate as an input.
Feedthru
control signals via I2C.
When operating the HL remotely which
many users do, it would be nice to be able to use the HL to send and
receive control information to be able to do things like monitor the
shack voltage/current, switch antennas, operate an antenna tuner and
receive a “tune complete” signal as a sample of possibilities.
The HL2 would be powered up all the time and able to respond to
control commands. The control console should be separate to the PC
console software driving the HL to avoid having several authors
having to customize software to cope with the control signals which
are really peripheral functions rather than radio functions.
Currently I control and monitor with a separate application but the
HL2 already has an ether connection to my remote site and this is a
duplication.
Separate pure
signal input
A dedicated input presenting 50 ohms forming the
shunt path with a 470 ohm series leg to the RX in as an L pad.
+17 dBm for
transverters
A separate sma connector perhaps switched on by
the protocol 1 address 9, 8th bit but there may be better
suggestions
5 Watts (+37
dBm)
Exactly as at present with interaction on the transverters
+17 dBm so it is off when the other is on.
Onboard I2C
signal level buffering
The buffer here
here
should be on board to enable a robust extension of HL filter
switching to high power amplifiers vi I2C with good RF immunity. If
the remote control is introduced the same I2C bus as the filter
switching probably could be used and only a single I2C line needed
Separate
receiver input
An sma connector for a separate RX input. This
should be connected to a jumper so that the RX in can be connected
to the changeover relay or directly to the sma to manage the cases
where an amplifier etc has separate RX and TX connections and
attends to the aerial switching - a very common scenario.
PTT leads the
RF by 20 mSec
Give time for antenna switching etc. to occur.
There is much to consider here as break-in CW is affected and most
of the PC console software has addressed this anyway but it needs
consideration.
Graeme,
Agreed 99%, especially support for a separate receiver input as this is essential for me and also for transverters.
PTT lead time should really be a software option I think, rather than hardware.
From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of Graeme Jury
…
Why wait? Just use a USB ethernet adapter on your tablet today.
From: herme...@googlegroups.com <herme...@googlegroups.com>
On Behalf Of Graeme Jury
Sent: Friday, December 3, 2021 23:31
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Thoughts on Future SDR Projects (was Re: OpenHPSDR protocol)
Hello Simon,
--
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/52b23c74-edff-453f-99f6-c258dfa1d782n%40googlegroups.com.
Yes,
I’ve often wondered why SDRs (and other stuff) don’t have a USB socket where you connect a Wi-Fi dongle, I’m going cable-free here. For TX Wi-Fi does have drawbacks, you must know what you are doing.
Also, ALC is bad idea IMO for solid-state stuff – best option is to turn the gain down on the exciter. If seen some shocking signals using ALC.
80 – that’s ancient? I’m only 64 (I think).
From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of Graeme Jury
Sent: 04 December 2021 07:31
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Thoughts on Future SDR Projects (was Re: OpenHPSDR protocol)
Hello Simon,
--
--
You received this message because you are subscribed to a topic in the Google Groups "Hermes-Lite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hermes-lite/JTdxzmjO_zI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/373b3f48-5269-4b87-9af8-7f052741d5dbn%40googlegroups.com.
I liked i2c because it was from the existing HL2 to reduce external cable count and is already supported in software today at least for the J16 pattern section mechanism. Without SDR app modification or external programs, that limits the i2c usefulness to the 7 or 8 io ports.
Being a user of several SDR app, piHPSDR on RPi mostly, running external apps would only be attractive if they had the means of keeping in sync with the SDR app and capable of being fully headless for seamless remote ops. True CAT port data may be enough to do most things with some added messages as it does not today share data LO and IF frequencies.
Since this is future talk, and we accept changes will be needed to likely all SDR apps, then any better solution will work. It could be an internal i2c to 1 wire conversion inside the box for example.
The existing serial port in the HL2 (and related protocol extensions) could be revised to pass through the actual CAT port data from the SDR app rather than just the locally inferred band data as it does today. Then you can add any useful data like LO, offsets, etc. With the concept of addressed serial messages one could do shack in the box functions like rotator control.
Mike
PTT leads the RF by 20 mSec
Give time for antenna switching etc. to occur. There is much to consider here as break-in CW is affected and most of the PC console software has addressed this anyway but it needs consideration.