Discussion of next-gen HL2 interface board

[Bill Cox]

IIUC, Steve would prefer for design discussions to happen on the list, rather than private emails.  I'd like to see if we can come to a consensus on what we want the interface card to do, and roughly the architecture.  Currently, a number of folks on this list know far more about this than me, so I hope you all will educate me.  I'd like to design this for the group, and get it fabbed, if no one else is already doing it.  I'll take whatever help is offered.

Interface to the interface board

I'm leaning towards making it a "hat" that floats either above the DB1 or DB7 connector.  Both give access to the I2C bus, which so far sounds like the right bus for the interface board to live on.  DB7 has access to the signal that keys the external amp, EXTR.  DB1 has access to the FPGA's UART.  However, the FPGA could send us band-change info (currently on the UART) and tell us that the amp is being keyed over the I2C bus, IIUC.  The choice of DB1 or DB7 probably depends on the functionality we want for the interface board.

Interface between HL2 and other open-hardware devices

We might be able to modify open-hardware designs to be compatible with our preferred interface, rather than having HL2 attempt to support lots of open-hardware interfaces.  What would our prefered interface be?  Would it be similar to our UART based interface to the Hardrock50, which allows an HL2 to control only 1 peripheral, or should it be more like USB or I2C which could allow a single HL2 to control multiple peripherals?

Currently, the HL2 -> HR50 interface board uses 3.3V UART signaling, which is understood by the Hardrock50, and probably a lot of other devices.  However, the Hardrock50 also has USB, as do many other peripherals.  Is USB an option?  Usually USB with a fairly complex driver, but we don't have a CPU in HL2.  I don't know if we can afford a USB master in the gateware.  On the positive side, a single USB master could support any number of peripherals, whereas UART supports only 1.  Here's a simple-ish USB host core using ~400 registers and LUTS.  Are we this constrained on the FPGA?

Using I2C signalling, amplified to 12V with bidirectional bus drivers was suggested as an option.  I'm not sure how to assign different devices different addresses on an I2C bus when peripherals can be mixed and matched.  Was this scheme meant to work with multiple peripherals on the same 12V I2C bus?  Cool if so, also a bit scary.

One concern with 3.3V UART is that the current UART to the Hardrock50 is glitchy when the Hardroc50 is transmitting.  Some ham radio equipment uses opto-couplers, or digital-isolators.  Should we support digital isolators or opto-couplers?

Supporting various commercial devices

The interface to varios radios and power amps seems to be all over the map, which is why we want a microcontroller on the interface board.  What features are required to support a broad set of commercial interfaces?  For instance:

• What voltage ranges are needed?
• Do we need an A/D or D/A?
• How many I/Os do we need?  Are 9 enough?
• Do many require USB?
• Do many require UARTs?
• How could we support opto-couplers/digital-isolators?

What microcontroller should we use?

I'd love to use RISC-V based microcontrollers, but cheap RISC-V microcontrollers are not yet available.  Some questions:

• Can we use an ARM based microcontroller?
• How do we keep noise from the microcontroller from interfering with the radio?
• What peripherals do we need?
• How many I/Os?

Feel free to post any ideas/thoughts.

73, Bill ak3q

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

There's already work being done within the HL2 ecosystem using a Teensy 4.0 ARM microcontroller for remote keying and audio.  Perhaps another Teensy LC or 4.x on a carrier PCB connected to DB1 or DB7 (or both!) could be flexibly used to offload the FPGA from all custom I/O tasks, thus leaving more room in the FPGA for potentially enhancing DSP and/or networking stuff.

I'm currently using a colocated headless Raspberry Pi 4 for IO, but that requires a separate case, a network switch, and another power supply or regulator for the Pi and the network switch.  A more integrated solution would be more portable and easier to set up.

73,

Ron

n6ywu

[Franz]

I think a Raspberry Pico would be a good option as your microprocessor. Cheap, lots of IO, USB in master or slave mode, programmable PIO, Python coding option, excellent support.

73, Franz DO3PBE

[Robert Benedict]

I second the idea of using a Pi pico. It's a great little device.

The Teensy keyer has been asleep for some time if not actually dead. I built one that I use locally with a side tone speaker and without the midi complex dysfunction. I could never get my IDE to compile  Steve's source with it's modified core and could only load his image. I don't think it ever fully functioned for anyone and IIRC Steve was going to change hardware so I stopped messing with it. The midi settings on the different PC software apps that did support midi for control varied and were a pain to deal with.

    Bob  KD8CGH

[Bill Cox]

IMO, these are 3 great suggestions:

• Us a Tinsy, which could leverage current HL2 open-hardware efforts
• Use a Raspberry Pi Pico, which is about as functional as a Tinsy, but only $4
• Embrace the octopus: Add shack control functionality with an extern headless Raspberry PI

I've ordered a Raspberry Pico.  I already have a couple of Tinsy boards and a few Raspberry Pis.  I have a dedicated HL2 now on my workbench for testing, and I'll try to see if the Pico causes interference with the receiver when running inside the case.

I honestly don't have enough information to figure out the best path.  The first 3 suggestions are all better than what I had in mind.  Can we discuss Pros/Cons?  Here's my highly incomplete list:

Tinsy

Pros:

• Already in use in related HL2 open-hardware project(s)
• Excellent functionality, e.g. USB, lots of GPIOs, UART, etc)

Cons:

• Expensive compared to Raspberry Pico
• May cause interference (I need to test this)

Raspberry Pico

Pros:

• Excellent functionality, e.g. USB, lots of GPIOs, UART, etc)
• Cheap compared to Tinsy

Cons:

• A newcomer, so we can't leverage the work done so far with Tinsy
• May cause interference (I need to test this)

Headless Raspberry Pi

Pros:

• Maybe a cleaner platform for full shack control
• Could also be configured to run SDR software, with remote access via something like FreeRDP or VNC + Mumble
• If done right, a Pi-based addition to an HL2 kit could be easier to set up than my Linux-laptop based solution.
• Fits my "octopus" model: My shack is already an octopus.  Embrace it.,.

Cons:

• More expensive than microcontroller based interface solutions
• Requires a local routing switch: Currently $16 form Amazon.
• Power supply (maybe $5), ethernet cable (maybe $5)
• Raspberry PI 4's are currently out of stock globally
• May make shack control more difficult: We can't expect all HL2 users to be good with SSH, and maintaining a Linux box.
• Less powerful than x86 based headless solutions: Is the remote access via Raspberry PI good enough?

I just saw Robert's post above.  Thanks for the info, Robert!  Unless others can think of a good reason to keep Tinsy on the list, I would vote we drop it.

Is it possible to overcome the complexity issues associated with using a Raspberry PI 4B for shack control?  E.g. offer an SD card preloaded with a stable headless solution, and a web server interface for shack control, along with RDP/VNC access?  I find the latency introduced with Mumble to be quite high (sometimes multiple seconds).  I put up with it because I require remote control of my shack, but frankly Mumble isn't doing the job very well.

73, Bill ak3q

--
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/29a400cb-70e6-4eea-9b08-c80d53b23df2n%40googlegroups.com.

[Bill Cox]

More thoughts on the Raspberry PI shack control solution...

Let's keep in mind a typical use case we're trying to solve:  A ham has both an HL2 and Hardrock50, and wants the HR50 to key faster, and automatically change bands when the HL2 changes bands.

The little boards Steve sent me, which I built up for this task, work well for exactly this purpose.  They seem pretty popular: I've shipped about 26 kits so far if  I've counted correctly, and have only 14 left for folks who haven't yet asked for one.  I've also kept 3 for myself and accidentally destroyed one.  Immediate demand seems to have dropped off, thankfully!

If we'd asked folks to instead install a Raspberry PI for shack control, how many takers would we get?

I think maybe these are two separate projects.  An interface board inside the HL2 is a well bound project, and something I can probably help make happen in my spare time over the next several months.  Long term, I'd like to help refactor the software to make it work better when remotely controlled.  Basically, I'd like a nice GUI like Quisk, but running on a tablet or phone anywhere in the world, controlling a remote computer which is connected to the shack over an Ethernet cable.  This is a much larger project for later.

I really like the idea of the Raspberry Pico inside the HL2.  I guess I'll find out how bad the interference is soon.  Does anyone have any ideas for reducing interference from the interface board?

73, Bill ak3q

[Robert Benedict]

Bill

  The teensy keyer was basically a K3NG keyer with added midi functionality. Unless you are considering midi you don't lose anything.

   At a quick check I see the Raspberry Pi 4, 4 GB available at Vilros ($55), Canakit ($55)  and Amazon ($99).

  The question, as always, is what problem are you trying to solve. If you want some integrated "in box" smarts I think a Pi pico is a great choice. If you want to run SDR apps you need much more.

     Bob   KD8CGH

[Bill Cox]

On Sat, Oct 2, 2021 at 7:23 AM Robert Benedict <rka...@gmail.com> wrote:

Bill

  The teensy keyer was basically a K3NG keyer with added midi functionality. Unless you are considering midi you don't lose anything.

   At a quick check I see the Raspberry Pi 4, 4 GB available at Vilros ($55), Canakit ($55)  and Amazon ($99).

  The question, as always, is what problem are you trying to solve. If you want some integrated "in box" smarts I think a Pi pico is a great choice. If you want to run SDR apps you need much more.

     Bob   KD8CGH

I 100% agree.  Let's solve the simpler interface problem first.  The Raspberry Pico looks awesome for this.

73, Bill ak3q 

[Tom Moll]

I have probably missed relevant related threads, so please excuse my ignorance.

So far this thread seems to be focused on what the solution is without having stated what the goals / objectives / problems / design parameters and constraints, etc. are.

A clear understanding of that might invite more participation in the discussion.

73, Tom N0BS

[Bill Cox]

I frankly wasn't entirely clear on the goals here to start, but I think I can be more clear now.  The primary goals:

• Provide reliable control of a variety of peripherals attached to the HL2, directly from the HL2
• Provide telemetry and other low-bandwidth feedback from these peripherals
• More specifically, provide improved support for the Hardrock50

Stretch goals:

• Support multiple peripherals at the same time
• Provide reliable control even when a high-power amp is keyed (may require isolators)
• Provide a hacking platform for folks to do other cool things

Are these the right goals?  Is anything missing?

73, Bill ak3q

--

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/cc3209e0-ea3f-4fb3-ad56-4f16cde155f7n%40googlegroups.com.

[Bill Cox]

I'll add one more goal:

• Aim for making a kit available to everyone at a low cost, without Bill having to solder together and ship each kit :)

73, Bill ak3q

[Matthew]

Against your primary goals, it sounds like you are in micro-controller territory rather than needing a full blown processor. An ATTINY chip from Microchip (formerly Atmel) would be suitable. The ATTINY414 is $0.71 (from Digikey) can be programmed over a simple USB TTL UART (UPDI), has i2c, spi, uarts etc. and 20 pins. You could probably get a total BoM cost less than $5 depending on what you add.

73 Matthew M5EVT.

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

A Raspberry Pi 4 can be programmed using self-contained Linux development tools.  One question for using any of microcontrollers: Teensy 4.x,  ESP32, Raspberry Pi Pico, or ATTINY, etc., is which tools are most available and cross platform (e.g. all of Wintel-64, Pi Linux, and M1 Mac supported) ?  And which embedded system development tools, or on-board microPython, Tiny Basic, et.al., are a typical HL2 user most likely to be able to use to whip up some HL2 support for connecting to their brand new next generation of HR-50++, ATU-100-QRP, 6M transverter, and etc. ?

73,

Ron

n6ywu

[si...@sdr-radio.com]

I like the Pi Pico suggestion, the Arduino IDE supports the Pi Pico.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/4af1fe7f-58d3-4936-a9f2-ca0023d38c5an%40googlegroups.com.

[Christian Veith]

Hi Simon,

The PI Pico is an excellent little toy. And I think it has some pro's when it comes to signalling purposes like the programmable io's.

You can offload the hardware protocol handling from the main core's program. Just tell the pio so send something and an offloaded routine handles all your io.

Even when putting the full Pico board to a PCB it just adds 4€ to the bill. With the RP2040 IC without the board it would be even cheaper.

Programmable via C, MicroPython offers a large target group.

A con is the strict 3.3V IO voltage but when it comes to interfacing other devices like PA's, Tuners, aso. It would be always a good choice to build in some form of additional protection for decoupling and isolate the lines.

Just my 2 cents.

Best regards

Chris, DL5CV

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/003701d7b7bb%242018e9f0%24604abdd0%24%40sdr-radio.com.

[si...@sdr-radio.com]

Yes,

 

Arduino IDE runs on Windows, Linux etc. and supports C – maybe not the very latest & greatest standard but at least a very usable amount. Getting to grips with the PI Pico is one of my goals for 2022, maybe write a keyer or something…

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CAEUKqYzZUeJ9%2Brtmegysxjq09Vaw5S6_bZ9d6ZHEfgef_viNZw%40mail.gmail.com.

[Robert Benedict]

Simon

  I also have been thinking about a keyer, but just implementing the K3NG software. The pico has a both a "slow" (ISR based) PWM and a faster hardware based PWM Arduino libraries that might allow relatively good audio without extra hardware.

PS - thanks for all the great software

  

     Bob   KD8CGH

[Bill Cox]

I feel like we should consider supporting USB 1.1 as a host, and rule it out only if it adds too much complexity or cost to the interface board.  This would solve the multiple peripheral issue, and enable us to support more peripherals.

It sounds like adding a $4 Raspberry Pico module to the interface board is a simple way to add USB support, at least if it does not produce too much interference with the receiver.  We'd still need level shifters, I/O protection, and maybe isolators as well, so we can't just use a bare Raspberry Pico and be done.  I'm used to having to pay FTDI $3 for their USB interface chips, so $4 for a USB host that also includes a popular high-end microcontroller sounds good to me.

It seems awkward to talk to the I2C bus from the host running the SDR software, and then have a USB host in the HL2, but if practical, it would solve a lot of interface problems.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/70fe0e93-3ac3-4719-ace8-f8fe143f35f9n%40googlegroups.com.

[Pencoys]

If its still available, I would like the CF-706, thanks, Mike G8NXD

On 2 Oct 2021 at 19:27, si...@sdr-radio.com wrote:

From: <si...@sdr-radio.com>
To: "'Hermes-Lite'" <herme...@googlegroups.com>
Subject: RE: Discussion of next-gen HL2 interface board
Date sent: Sat, 2 Oct 2021 19:27:15 +0100

I like the Pi Pico suggestion, the Arduino IDE supports the Pi Pico.



Simon Brown, G4ELI

<https://www.sdr-radio.com/> https://www.sdr-radio.com

* Provide reliable control of a variety of peripherals attached to the HL2,
directly from the HL2
* Provide telemetry and other low-bandwidth feedback from these peripherals
* More specifically, provide improved support for the Hardrock50

Stretch goals:

* Support multiple peripherals at the same time
* Provide reliable control even when a high-power amp is keyed (may require
isolators)
* Provide a hacking platform for folks to do other cool things

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/cc3209e0-ea3f-4fb3-ad56-4f16cde15
5f7n%40googlegroups.com

<https://groups.google.com/d/msgid/hermes-lite/cc3209e0-ea3f-4fb3-ad56-4f16cde1
55f7n%40googlegroups.com?utm_medium=email&utm_source=footer> .

--
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/4af1fe7f-58d3-4936-a9f2-ca0023d38
c5an%40googlegroups.com
<https://groups.google.com/d/msgid/hermes-lite/4af1fe7f-58d3-4936-a9f2-ca0023d3
8c5an%40googlegroups.com?utm_medium=email&utm_source=footer> .

--
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/003701d7b7bb%242018e9f0%24604abdd
0%24%40sdr-radio.com.

[Reid Campbell]

Hi Group,

I would also like to see a Pi Pico in there. I got one a couple of weeks back and have had a quick play using the Platform IO IDE. With a high performance processor we could maybe off load some of the processing from the FPGA to the Pico. Primarily I'm thinking about some of the IP workload (DHCP and the like) which would free up more resources for extra receivers. This would require some sort of high speed interface between the Pico and the FPGA.

While I'm at it, some other thoughts on a expansion board.

I think the board should be full length of the HL2 and N2ADR. This would allow extra connectors to be mounted on the ends of the board for extra interfaces and reduce point to point wiring. New end plates could be made to accommodate the new connectors

The board should pick up all the connection points that are on the HL2 board. You don't have to use them all but increase the usefulness as an experimenters board. I'm talking about DB9, DB17, etc.

Add the ability to have a separate Rx antenna switched by relay using the current N2ADR signal line.

Add dedicated transverter interface which would allow other bands to be integrated without dedicating a HL2 to the job. The idea would be to have a tunable IF at 45MHz which used undersampling. This has already been shown to work a 50MHz but the current sample rate causes a issue at 2 time the fundamental frequency. I don't think 45Mhz would have a problem. The undersampled image should appear about 31MHz in the digital world but in reality we just have diplex 1-30MHz and 45MHz together in the analogue world.

For transverter Tx, you need to pull of the raw DAC signals which are available at DB3 (remember what I said about making these signals available on the expansion board) and band pass filter. You would also need to turn off the Tx x2 interpolation. This might also be a way to produce signals for the new 8 metre band?

So, that's a lot of work but could be broken into individual bits and integrated in the final board. Not everybody will want it all but they only have to add the components they need to full fill there needs.

Build it and they will come.

Cheers

Reid
Gi8TME/Mi0BOT  

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/008001d7b7c5%241e1ebc10%245a5c3430%24%40sdr-radio.com.

[Bill Cox]

On Sun, Oct 3, 2021 at 5:22 AM Reid Campbell <scumballc...@gmail.com> wrote:

Hi Group,

I would also like to see a Pi Pico in there. I got one a couple of weeks back and have had a quick play using the Platform IO IDE. With a high performance processor we could maybe off load some of the processing from the FPGA to the Pico. Primarily I'm thinking about some of the IP workload (DHCP and the like) which would free up more resources for extra receivers. This would require some sort of high speed interface between the Pico and the FPGA.

I'm going to give it a try.  My Pico comes this week.  How about mounting the Pico in the new back panel so that its USB port is available?  It might be tight, the Pico floating over the expansion board.  Worse case, we lose the area under the Pico.

Will the Pico cause too much interference?  We might need it to mostly be in sleep mode.  Offloading the FPGA sounds good, but not if it causes interference.

 

While I'm at it, some other thoughts on a expansion board.

I think the board should be full length of the HL2 and N2ADR. This would allow extra connectors to be mounted on the ends of the board for extra interfaces and reduce point to point wiring. New end plates could be made to accommodate the new connectors

I think that's a great idea.  I'm waffling between a DB9 serial port and a USB port.  Why not both?  Having the board extend all the way to the new back panel should give it mechanical stability and eliminate ribbon cables.

Is the N2ADR board cool enough to have the reduced air flow if we put a board the same size over it?should we add any venting in the back plate?

 

The board should pick up all the connection points that are on the HL2 board. You don't have to use them all but increase the usefulness as an experimenters board. I'm talking about DB9, DB17, etc.

Could we do what Steven and Jim did, and have it be two boards, connected with a connector board like the one used to connect the HL2 to the N2ADR?  Alternatively, there could be one board with just interface stuff, and a single board with both interface and some cool new stuff.

 

Add the ability to have a separate Rx antenna switched by relay using the current N2ADR signal line.

Please excuse my ignorance, but what cool things could I do with an additional Rx input?

 

Add dedicated transverter interface which would allow other bands to be integrated without dedicating a HL2 to the job. The idea would be to have a tunable IF at 45MHz which used undersampling. This has already been shown to work a 50MHz but the current sample rate causes a issue at 2 time the fundamental frequency. I don't think 45Mhz would have a problem. The undersampled image should appear about 31MHz in the digital world but in reality we just have diplex 1-30MHz and 45MHz together in the analogue world.

I'd love to see a good integrated transverter.  I currently use 2 HL2s, one for HF, and one for the 2m band.  What bands do you have in mind?  Any internal amp?

I have a cheap Ukrainian transverter.  I can recommend it for the price, but I am envious of folks with the higher end transverters.  It seems to show that a 2-band transverter could fit in the case, with a modest power amp.  Mine is in theory (not measured) 10W on 146MHz, and 3W on 440MHz.

For transverter Tx, you need to pull of the raw DAC signals which are available at DB3 (remember what I said about making these signals available on the expansion board) and band pass filter. You would also need to turn off the Tx x2 interpolation. This might also be a way to produce signals for the new 8 metre band?

What is the Tx x2 interpolation?

 

So, that's a lot of work but could be broken into individual bits and integrated in the final board. Not everybody will want it all but they only have to add the components they need to full fill there needs.

I do think people will want an interface board without a transverter.  How much more would a full sized board cost vs an N2ADR sided board?

 

Build it and they will come.

Especially once the chip shortage is over.  Are you signing up for the transverter portion of the design?  I've never designed a transverter before, so some other engineer will have to lead on the design.  I can probably help with prototyping, some board layout, kitting for the fab and such.

73, Bill ak3q

[Steve Haynal]

Hi Bill and Group,

Thanks for your initiative on this. First, I have so many other unfinished projects and demands, plus so little hobby time that I can't commit much to this. But I do think a small microcontroller board would be a nice addition to the HL2. Users often ask about ways to interface to a PA, antenna tuner, transverter or other peripheral hardware. It is difficult to write FPGA code for most people, plus it uses limited FPGA resources for what are typically "slow" applications better suited for a microcontroller. The limited set of IO we currently have in the FPGA (HR50 FA commands to the HR50 only, not the full bidirectional command set, ATU AH4 tuner support, voltage band select) is evidence of the difficulty. So I see this project as a way to simplify and consolidate what the FPGA has to do for IO by only communicating with a microcontroller, but then the microconroller opens more IO possibilities at a lower bar of entry for a typical user.

The teensy keyer is no dead as mentioned in this thread. I just haven't gotten around to laying out the PCB. I'll try to move my work to github in case someone would like to do the layout. The main point of the teensy keyer is not just a midi interface, but it is a USB sound device. This allows for low latency sidetone at the keyer while the HL2 can still be remote. It doesn't cater to just local CW operation right in front of the HL2. It is possible to key via midi, serial or a direct cable connection. It is still very experimental and currently difficult for most to get working, but I do have positive reports from several users. This is different from the "HL2 interface board" discussed in this thread as the teesny keeyer is meant to sit by the operating PC for low latency CW, but the "HL2 interface board" is meant to sit in the HL2 even at a remote location and provide an easy way for a user to "glue" to and communicate with some other remote peripheral.

I think the Raspberry Pi pico or some other rp2040 board, or any of the Arduino boards and processors would be a good choice here. I think it is more important to have a rich and easy to use development environment. Also, it may be easier and faster to start with a ready-made board that itself plugs into another PCB. In my opinion this is more important even if it increases the cost by $5 to $10. We should discuss a more custom PCB if this ever becomes something we want to produce 100s of. I think the full blown Raspberry Pi or even Teensy is overkill for this application.

To begin with, I think the communication between the FPGA and "HL2 interface board" should only be i2c. We have already added basic i2c writes and reads in the openhpsdr protocol. The microcontroller could then convert the i2c information and commands from the FPGA to do what it is programmed to do on some other external microcontroller interface, even a USB host interface. This could all be done with no change to the current FPGA gateware.

I am also willing to update the FPGA gateware to send a regular periodic command to the "HL2 interface board" via i2c. This would be synchronized with the commands the FPGA receives from the host over ethernet. It would contain the command and control words that are in every packet from the host and possibly a few extra bytes. This would allow the microcontroller to keep a local copy of all state sent by the host (frequency changes, filter settings, tx state, etc.). This would enable the microcontroller to initiate some IO without having to modify host PC software.

Regarding connectors, DB7 is probably the best choice. It is a 3.3V interface. You have access to i2c and power. The board would be a redesign of the small 40-pin jumper board that currently connects the HL2 to the N2ADR filter board. That board would be expanded to include the microcontroller and connections as well as still connect the HL2 to the N2ADR filter board.

DB17 can also work. It has 3.3V and i2c, but the gateware uses that i2c differently and would have be to updated to support the basic reads and writes plus command broadcast on that i2c interface.

DB1 has the most expansion potential. For example it would be possible to use the extra pins for a high speed interface to send/receive audio data with the FPGA. It is a 2.5V interface to support connecting two synchronized radios. (Lower voltages means interfaces can run at higher speeds.) We can't run a microcontroller off of 2.5V because it is a limited current power supply. There is a way to convert this interface to 3.3V by removing a ferrite bead, but that process is trivial for some users and very intimidating for other users. I prefer stay away from requiring board modifications given the wide variety of HL2 users.

There is no 5V on the HL2. Most existing microcontroller boards are setup to use a 5V supply. You would have to be sure there is a way to power the board or microcontroller only from 3.3V otherwise the power supply design becomes trickier.

It is helpful to take a look at some other small microcontroller boards, even possibly choose one for this project:

https://www.adafruit.com/product/4888

https://www.sparkfun.com/products/18288

https://www.sparkfun.com/products/17720  (I really like the MicroMod idea)

https://www.seeedstudio.com/rp2040.html

73,

Steve

kf7o

[Bill Cox]

Here's a straw-man concept, taking Steve's input into account:

• An RP2040 based board, with the Pico as the default choice simply because it is cheaper.
• Control of the interface board would be entirely over I2C.
• Use DB7, and extend over the N2ADR board all the way to the backplate.
• Have a new backplate to support the new connectors and support the interface board.
• Connectors include DB9, and the Pico's MicroUSB connector.  Anything else?  A second RX connector was suggested, and the existing back plate has a hole for RF3.
• Connectors would be directly soldered to the board, so no additional wiring is needed.
• The microcontroller board would be directly soldered to the interface board, with the microUSB port accessible through the backplate.
• The interface board would have a 5V regulator to power the RP2040 board and when in host mode, provide 5V USB power of 100mA (one unit).
• Provide a connection option for additional boards that want to access DB7, such as a transverter.  If there is any new SMA port, also make that accessible.
• Provide some GPIOs for controlling additional boards, in addition to the DB7 signals.
• Make the DB9 signals highly programmable, capable of 5V, and bullet-proof, so folks can short pins, ground the VCC pin, etc, without damaging the interface board.

Does this sound reasonable?  Do we need to add an opto-coupler interface?  Anything else?

73, Bill ak3q

--

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/d3e9109b-7c54-452e-8028-21300e2c2586n%40googlegroups.com.

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

Does the microcontroller carrier board also need to integrate with, or have a substitute for the current HL2's optional fan control circuitry?  If the carrier board extends to the back plate, does it need to have airflow cut outs and/or mounting points for an optional fan?

73, 

Ron

n6ywu

[Bill Cox]

I've added fan control as a feature in the straw man proposal.  Please feel free to comment on the doc:

Straw Man Interface Board Proposal

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/985b9738-d76d-49b9-a4fc-40d95927e9f9n%40googlegroups.com.

[Reid Campbell]

Hi Bill,

See below.

Cheers

Reid
Gi8TME/Mi0BOT  

On 03/10/2021 21:56, Bill Cox wrote:

On Sun, Oct 3, 2021 at 5:22 AM Reid Campbell <scumballc...@gmail.com> wrote:

Hi Group,

I would also like to see a Pi Pico in there. I got one a couple of weeks back and have had a quick play using the Platform IO IDE. With a high performance processor we could maybe off load some of the processing from the FPGA to the Pico. Primarily I'm thinking about some of the IP workload (DHCP and the like) which would free up more resources for extra receivers. This would require some sort of high speed interface between the Pico and the FPGA.

I'm going to give it a try.  My Pico comes this week.  How about mounting the Pico in the new back panel so that its USB port is available?  It might be tight, the Pico floating over the expansion board.  Worse case, we lose the area under the Pico.

It could sit in the area over the Ethernet connector, on the digital side of the board.

Will the Pico cause too much interference?  We might need it to mostly be in sleep mode.  Offloading the FPGA sounds good, but not if it causes interference.

 

While I'm at it, some other thoughts on a expansion board.

I think the board should be full length of the HL2 and N2ADR. This would allow extra connectors to be mounted on the ends of the board for extra interfaces and reduce point to point wiring. New end plates could be made to accommodate the new connectors

I think that's a great idea.  I'm waffling between a DB9 serial port and a USB port.  Why not both?  Having the board extend all the way to the new back panel should give it mechanical stability and eliminate ribbon cables.

Is the N2ADR board cool enough to have the reduced air flow if we put a board the same size over it?should we add any venting in the back plate?

If there is concern, a small fan could place on the board to blow air down on the PA section as that is where the majority of the heat is generated.

 

The board should pick up all the connection points that are on the HL2 board. You don't have to use them all but increase the usefulness as an experimenters board. I'm talking about DB9, DB17, etc.

Could we do what Steven and Jim did, and have it be two boards, connected with a connector board like the one used to connect the HL2 to the N2ADR?  Alternatively, there could be one board with just interface stuff, and a single board with both interface and some cool new stuff.

That may work, just need to think carefully on the division of functionality between the boards. Two boards will increase the cost but one large board is over the 100mm x100mm sweet spot for some of the PCB fab houses.

 

Add the ability to have a separate Rx antenna switched by relay using the current N2ADR signal line.

Please excuse my ignorance, but what cool things could I do with an additional Rx input?

Sometime you get better performance using a separate Rx antenna compared to your Tx one. This is particularly true of the low bands, 160 & 80 metres. I'm thinking beverages or loops. There is a control signals already defined in the protocol to allow switching to a separate rx antenna. The implementations would take the form of a switch (relay or solid state) and possibility a filter to limit the bands of interest and give better dynamic range. Maybe that could be switched as well.  

 

Add dedicated transverter interface which would allow other bands to be integrated without dedicating a HL2 to the job. The idea would be to have a tunable IF at 45MHz which used undersampling. This has already been shown to work a 50MHz but the current sample rate causes a issue at 2 time the fundamental frequency. I don't think 45Mhz would have a problem. The undersampled image should appear about 31MHz in the digital world but in reality we just have diplex 1-30MHz and 45MHz together in the analogue world.

I'd love to see a good integrated transverter.  I currently use 2 HL2s, one for HF, and one for the 2m band.  What bands do you have in mind?  Any internal amp?

I see the expansion board only having the band pass filtering for Rx and Tx, switching of the signals and selection lines to enable a specific transverter. The actual transverting would be done by a separate PCB, dedicated to the band of interest. It would have the mixers and PA stages. The transverting board could be single or multi band.

I have a cheap Ukrainian transverter.  I can recommend it for the price, but I am envious of folks with the higher end transverters.  It seems to show that a 2-band transverter could fit in the case, with a modest power amp.  Mine is in theory (not measured) 10W on 146MHz, and 3W on 440MHz.

For transverter Tx, you need to pull of the raw DAC signals which are available at DB3 (remember what I said about making these signals available on the expansion board) and band pass filter. You would also need to turn off the Tx x2 interpolation. This might also be a way to produce signals for the new 8 metre band?

What is the Tx x2 interpolation?

The modem chip normally runs at a sampling frequency of 76.8 MHz for rx but twice this for tx. If you want a under sampled signal at 45MHz, you need a tx sampling frequency of 76.8, so the second aliasing zone is in the correct place. There is a link to a 6 metre under sampling transceiver some where in the forums archives but I can find it at the minute.

[Bill Cox]

Thanks for the detailed info.  So, IIUC, we may want an additional RF port on the interface board, because:

• We'd like to attach to transverters as well as an HF antenna
• In some cases, it is better to have separate RX and TX antennas

In either case, the additional SMA connector would be low-power.

I'm confused about the filtering for a transverter.  I have an external transvert on an HL2 that converts VHF/UHF to 28MHz.  Assuming the transverter has the needed filters for the supported bands, why do we need additional filters inside the HL2?

73, Bill ak3q

[Bill Cox]

How much do folks prefer programming the Pico in MicroPython vs C/C++?

I'm asking because MicroPython support appears somewhat immature on the Pico.  There is a library for I2C controllers, but none for I2C responders (I'm using controller/responger instead of master/slave).  There is a community project on github, but the MicroPython multi-threading also appears.  Documentation for C APIs appears more complete.

I'm very comfortable in C/C++, but a goal of the interface board is to make writing peripheral control software more accessible.  How strongly do folks prefer MicroPython to C/C++?

My Pico arrived, and I'm blinking lights.  I should probably read how to program the FPGA next, and see if I can get the FPGA to control the  Pico over I2C.

73, Bill ak3q

[si...@sdr-radio.com]

C/C++ is the engineering language. Since I wrote my own C compiler in 1983 due to lack of a commercial compiler while working in Hemel Hempstead I’ve rarely used anything other than C/C++.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of Bill Cox
Sent: 05 October 2021 01:09
To: Reid Campbell <scumballc...@gmail.com>
Cc: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Discussion of next-gen HL2 interface board

 

How much do folks prefer programming the Pico in MicroPython vs C/C++?

[Steve Haynal]

Hi Bill,

Just a few thoughts. I do prefer MicroPython but think that can come later and you should use C/C++ if that is most comfortable for you. I use Python and C/C++ in my day job. We have a commercial product written in Python. Python is very popular:

https://spectrum.ieee.org/top-programming-languages-2021#toggle-gdpr

I would love to learn and do something in rust:

https://www.rust-lang.org/

The pico has a switching buck/boost voltage converter. These are a potential noise source. For 5V, you will either have to regulate Vsupply down to 5V and support a Vsupply as high as 18V (big drop means you will burn power with a linear regulator) or boost 3.3V up to 5V (only possibly with a potential noisey switching boost converter). There is no Vsupply on DB7 so you would have to extend the connector to get Vsupply. 

Why 5V? You can avoid any regulators by using 3.3V as that is native to the pico. It appears possible to power it directly via Vsys and bypass the regulator.

See:

https://www.raspberrypi.org/forums/viewtopic.php?t=300676

I've seen amateur radio peripherals such as the Icom AH4 which use some other standard like 12V for signalling. In these cases you will have to have a level shifter or "open-drain" style FET. Even if you must have 5V somewhere, it would be better to minimize what is connected to 5V so that if you regulate from Vsupply down to 5V you are not wasting much as heat with a linear regulator.

Will a PCB connected to DB7 clear the relays and CN1 if it is just above the N2ADR board? You may need a cutout for CN1. Even if it does clear, it will be close. We have had problems in the past with coupling between switching regulators and some inductors on the N2ADR board. This is why we have the setting to move the spurs on 160M. I am worried if there are switching regulators even closer to the N2ADR inductors that there will be coupling issues. You will at least want a solid ground plane in your board.

Will mechanical support by DB7 be enough? Currently the N2ADR board is supported by the enclosure slot. Any daughter board may need more mechanical support than just the DB7 connector.

73,

Steve

kf7o

[Franz]

Hi Bill,

I think the C++/Python question depends on who you want to modify the interface software. Engineers possibly prefer C++, but hobbyists, tinkerers, part timers and new programmers program in Python. The learning curve on the Pico for MicroPython is a fraction of that for C++.

73, Franz DO3PBE

[Alan Hopper]

Hi Bill and all.

just a thought, It would be nice if the software on the board could use some well defined way to report the features available and to give named access to them from the pc. This would allow people to add their own features to the board and sw at the pc end could automatically provided a gui to control it with no update needed.  SDR software could provide a basic property viewer or something more sophisticated to allow buttons and sliders etc. to be created. 

There is an example of this approach here  rc24/rxmain.c at aeebc08bc0ac31e3c588af7a6ce7f836a87a140b · ahopper/rc24 (github.com) 

This project also had the concept of routed messages so each hw or sw node could report what it was connected to, so another part of the system could discover the whole network and display and control all the settings available e.g. from a pc connected to the radio control transmitter you could see and control all settings on the transmitter, the receiver and any sensors connected the the receiver. Adding a new sensor or feature to any part did not require a change to the pc code.  The protocol also allowed for updating the sw on any node remotely and included a scripting language that could run on any node. 

I'm not suggesting using this code, I imagine there are standard libraries to do this sort of thing these days.

73 Alan M0NNB

[Bill Cox]

5V is only required for the USB 1.1 support.  Without it, connected USB devices often wont recognise the connection, even if they draw no power.  I think we could get away with a 100mA 5V source.

It is a pretty ugly situation.  At 18V, a linear regulator will burn 1.3W to deliver 100mA at 5V.

--
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/cb72671a-3c51-47da-a768-3e2746b0f694n%40googlegroups.com.

[Reid Campbell]

What I'm proposing is a IF interface at 45MHz, so you need the BPF to select that frequency. The transverters wouldn't need the filtering on their side, so reducing the component count pre transverter.

The link to the under sampling 6 metre transceiver using the HL1 is https://github.com/ji1udd/Hermes-Lite/tree/6M

The requirements. as I see it, for the transverter interface are :

Better support for current 28 MHz IF transverters
Support for custom IF frequencies, IE. 45 MHz
Support for  other under sampling work
SMA connector for transverter input
SMA connector for transverter output (the low power output already exists for 28MHz designs)
Transverter select lines, for multiple transverter
Transverter PTT line 

Cheers

Reid
Gi8TME/Mi0BOT  

[Reid Campbell]

I'm assume this is for host support to connect some form of peripheral equipment?  Would it not expect to be powered from the USB port, so potential requiring up to 500 mA of 5V.

Bill, do you have a use in mind for this port?

Cheers

Reid
Gi8TME/Mi0BOT  

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CAOLP8p5UMZUgoiR7ioA%3DzqVbjU47NSjCmB7E6wLw2pU8%2Bat4Ew%40mail.gmail.com.

[Steve Haynal]

Hi Bill,

I was wrong about the 18V. The max support is 16V. The power consumption does seem high, especially for those who want to operate on battery. Some options are to no always enable the 5V, perhaps have a jumper, so those not using it do not pay the power penalty. Or you can require those who want to use USB 1.1 host to also supply 5V from an external power source. I think it should be possible to power the pico as well as any "open collector" style fets only from the existing 3.3V.

73,

Steve

kf7o

[Bill Cox]

It sounds like the simplest solution is to ask users who want USB host functionality to provide 5V via an additional micro USB port that only has VSUP and GND connected.  We'd disable the switching regulator on the Pico, and run it off the 3.3V from the HL2.  Mechanical stability would come from the connector to the HL2 and N2ADR, as well as the DB9 connector screwed to the back plate.

The other option, of extending the connector 6 pins taller to access VSUP requires soldering headers onto the HL2 main board, which  I would prefer to avoid if possible.  Also, it would run into the Raspberry Pico, meaning we'd have to switch to something like a ItsyBitsy RP2040.  Maybe we should switch anyway?  It can still run the same MicroPython as the Pico, I believe.  I'll order one and verify this.  The only downside would be that it costs $8 in quantity 100, rather than $4 for the Pico, but we probably could reduce the board size.  There will be a ton of wasted space otherwize.

Should we have the board cover all of the N2ADR just to provide additional shielding with its ground plane?  In that case, we can use a $4 Raspberry Pico.  I've drawn this in the straw-man proposal, but if we can save $4 by having a smaller board, and if the additional shielding is not needed, I think I'd prefer the ItsyBitsy PR2040.

Either way, it looks like the board would fit OK over the relays, and we'll need a cutout around the EXTTR connector.

73, Bill ak3q

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/7bdfc541-0c13-4bf4-b1e9-809585b3b1a1n%40googlegroups.com.

[Christian Veith]

Hi Guys,

Another option would be to put the RP2040 chip directly onto the extension board. From what I've seen it requires minimal external circuitry and it's available für 0,82€ at Farnell.

We could than provide some more efficient power regulator to provide the different voltage levels for different io ports.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CAOLP8p68chJf-Mm4Gx_u5sp9YMHkaRqyiCmoUqqEUntSTDRDYQ%40mail.gmail.com.

[Bill Cox]

On Wed, Oct 6, 2021 at 12:24 AM Reid Campbell <scumballc...@gmail.com> wrote:

I'm assume this is for host support to connect some form of peripheral equipment?  Would it not expect to be powered from the USB port, so potential requiring up to 500 mA of 5V.

Bill, do you have a use in mind for this port?

I think USB is the natural choice for new designs for both radios and radio peripherals.  We can report back to the SDR software what peripherals are connected, and we can have any number of them in the shack.  For example, the HR50 has USB.

For connecting to older radio peripherals, we'll use the DB9 connector, and have the microcontroller select what signaling protocol to use on which pins.  I think options would include 3.3V signals, open-collector signals for higher external voltages, PWM, and even analog signals.  Hopefully, this will give users enough flexibility.

73, Bill ak3q

[Bill Cox]

On Wed, Oct 6, 2021 at 12:50 PM 'Christian Veith' via Hermes-Lite <herme...@googlegroups.com> wrote:

Hi Guys,

Another option would be to put the RP2040 chip directly onto the extension board. From what I've seen it requires minimal external circuitry and it's available für 0,82€ at Farnell.

Maybe, but I think probably not for the first rev.  I just checked the Pico BOM, and it has 51 components, and 28 unique types of parts.  There are just 3 ICs, of which the regulator we don't want is $1.50 at Digikey in 100-unit quantities.  The RP4030 is $1 in any quantity, and the flash chip is $0.52.  The components at our volume will cost more than $4, even without the regulator.  Also, all three chips are out of stock at Digikey.

 

We could than provide some more efficient power regulator to provide the different voltage levels for different io ports.

For the DB9, I was thinking of taking Steve's advice and offering just 3.3V, or open collector (maybe up to 20-ish volts),  That wouldn't take any new power source.  For USB hosting, an external wall wart is cheap.

73, Bill ak3q

[Steve Haynal]

Hi Bill,

Just a few more thoughts. You might consider putting the PCB in one of the slots on the other half of the clam shell, 10cm wide towards the back and above the N2ADR filter. This would require soldering some (5-6) wires to the N2ADR connector with a connector on the other end which attaches to your board. I'm not sure which is better and don't have strong opinions.

If the pico has some PWM outputs, it would be nice to support the band voltage switching:

https://github.com/softerhardware/Hermes-Lite2/wiki/Band-Volts

You could just have two copies of that circuit, one for the fan and one for the band volts.

Several IOs with "open-collector" FETs or level shifters would be nice and allow us to move the Icom AH4 ATU suppot to the Pico:

 https://github.com/softerhardware/Hermes-Lite2/tree/master/hardware/enclosure/endcaps/kf7o/hl2_40b#atu

I like this idea for IO. The interface to the FPGA is very simple via i2c and the FPGA sends/receives individual commands plus relays command words from the host yet we should be able to accommodate lots of various peripherals.

73,

Steve

kf7o

[PA3GSB]

Hi Bill, Steve and all,

Nice development.

For the radioberry juice board iam making the beta 2 design...

https://groups.google.com/g/radioberry/c/v-yENgAAbnE (juice beta 2) 

i also  had some pins left and makes it possible to connect to this new development!

Will  follow the develpment.

Have fun,

73 Johan

PA3GSB

Op zaterdag 9 oktober 2021 om 08:11:47 UTC+2 schreef softerh...@gmail.com:

[Michael Durkin]

I use an Arduino Nano to control an Amplifier and lowpass filters with my FT-817/818 ... consumption is 19ma for the nano ... i think my opto-isolators use way more power than that.

I might keep my HL2B9 if I could add an external HF PA to my setup ..

I liked the nano simply for the cost ... 

--

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/6d1ef7c1-f0fe-47ca-8678-d47032d74f04n%40googlegroups.com.

[Robert Benedict]

Steve

The Pi pico has 8 PWM channels and the Arduino IDE library supports  purely hardware-based PWM channels.

https://www.arduino.cc/reference/en/libraries/rp2040_pwm/

    Bob  KD8CGH

[Matthew]

What are the initial thoughts on what an i2c memory map might look like for this and how it might grow?

I developed a board and some firmware to send back temperature and current over i2c and allow control of 2 fans. I would like to ensure this uses the same i2c mm as the device proposed in this thread. It feels like this has potential to grow into a nightmare for PC software to support if not controlled carefully? (e.g. if someone is using an HR50, the PC software will poll a device place in the memory map compared with an HL2-MRF101?).

See here for schematic https://github.com/m5evt/hl2_extpamon/tree/main/hardware I think this is generic enough that people using ebay/alibaba power amplifiers could hook into this (within reason).

I've modified linHPSDR to get i2c data from this board every 200 ms. See here. (to see the level meters, right click where the HL2 temperature is displayed in the main window).

I am reading addr 0x01 and sending; byte 0 - temperature, byte 1 - current; byte 2 - status flags (fans, pa trip etc.); byte 3 ???

I think if byte 3 became SWR or FWD PWR (which I don't need for my application), this has overlap with data from an HR50? I had a quick look at the HR50 manual to try and implement a UART and send HR50 data back to a PC via HL2 i2c as a test. I noted that the data only comes at the end of a transmission, so for something like FT8, you won't get any info until you have been TXing for a (relative) while?

Is it best to grow the memory map organically via a page on the wiki that gets added to, or try and define a big memory map from the start?

73 Matthew M5EVT.

[Bill Cox]

Hi, Steve.  Sorry for the late reply, but I wanted to repair my original HR-50.  Jim sent me replacements for 4 capacitors and 5 relays that he suspected might be bad, and now my original HR-50 is fully functional.  My next hobby hours will be on the interface board project.  This will be much easier now that I have an HL2 and HR50 on my workbench without having to tear apart my functioning shack.

I can see advantages in using the slots on the top shell, rather than suspending the interface board by the N2ADR connector and the DB9 connector on the backplate.  For example, we could use the same edge connector trick to allow additional expansion boards on the top side.  I haven't figured out a good solution for supporting expansion boards if the interface board floats over the N2ADR board, blocking additional expansion boards.  I'm not sure which I'll prototype first.  Let me know if you have a preference.

Band selection by voltage, using the PWM output sounds good to me.  I'll add it to initial prototypes.

Thanks for all the support.

73, Bill ak3q

--

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/6d1ef7c1-f0fe-47ca-8678-d47032d74f04n%40googlegroups.com.

[Steve Haynal]

Hi Matthew and Group,

In the HL2, i2c transactions have at least two data frames. For example, writing to the Versa clock chip uses an address frame with 0xD4, the target address of the Versa chip or "chip address", followed by two data frames. The first data frame is typically address and/or command information. The second data frame is typically true data. Each microcontroller project should have a unique chip address. Currently we have these addresses in use: 0xd4, 0x34, 0x2c, 0x20. The HL2 supports a 7-bit address here so we have plenty available. For example, your ATtiny project (interesting project by the way) can use 0x01 and Bob's pico project can use 0x02. We should keep track of these assignments on a wiki page. It is hard for me to imagine more than a dozen microcontroller projects which are different enough that they each need a unique chip address.

Once assigned a chip address, the designer can use the two data frames as seen fit. I expect the first data frame byte will probably address into various functionality of that project as well as specify some command, and the second data frame byte will contain real data. I think it would be good to track these assignments on a wiki per project too.

The above covers project-specific transactions initiated from software. I would also like to periodically broadcast the command word received by the HL2 from the PC plus possibly some other bits of information over i2c. This would allow microcontroller projects to track state changes to make some independent decisions. Since there may be multiple microcontroller projects, I will assign a broadcast "chip address" and complete i2c writes to that address even if no device acknowledges. Microcontroller projects can listen and snoop messages to that address.

73,

Steve

kf7o

[Steve Haynal]

Hi Bill,

Fine business with your HR-50 repair. My preference is to first get a simple i2c client working on the Pico. We should be able to assign a chip address and then write/read dummy data to it via the existing hermeslite.py library. Also, I'd like to implement the broadcast packets in the gateware and make sure that a microcontroller client i2c can snoop these easily.

73,

Steve

kf7o

[Bill Cox AK3Q]

Sounds good to me.  As for mounting on the top -side slots vs being a hat/shield floating over the N2ADR board, I worry that without a ground plain between the interface board and the N2ADR, we'll get more interference from the microcontroller.

What is the best way to detect the noise?  I was thinking of driving a dummy load from the HL2, which results in very little QRM from other sources, AFAICT.  Then, I'd just look on all supported bands for any visible noise, and do a listening sweep of them as well, since apparently here is noise we can hear that is not visible easily on the Quisk graph.  Is something like that how you look for interference?  What is the best way to look for new noise while transmitting?  I have other HL2s if needed.

73, Bill ak3q

[Vince Vielhaber]

meant to send this to the group..

I had a couple of comments on mounting the board, but I see Bill noticed
one of them with the ground plane. But the other is, if you mount it
above the filter board and use a couple of jackscrews and nuts to hold
the DB9 to the back panel, you have all the rigidity you need.

I just did something for the HR2+ for PWM. Taka suggested using a 10K
and 10uf for a 1st order LPF and it worked perfectly.

Vince - K8ZW.

> <mailto:hermes-lite...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/hermes-lite/6d1ef7c1-f0fe-47ca-8678-d47032d74f04n%40googlegroups.com

> <https://groups.google.com/d/msgid/hermes-lite/6d1ef7c1-f0fe-47ca-8678-d47032d74f04n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> 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/CAOLP8p67MYSXk1KMp6Bp1scDShtGaya5dpWs-UZ-SMOH0JkdnA%40mail.gmail.com
> <https://groups.google.com/d/msgid/hermes-lite/CAOLP8p67MYSXk1KMp6Bp1scDShtGaya5dpWs-UZ-SMOH0JkdnA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
Michigan VHF Corporation -- nobucks dot net
K8ZW - http://www.hamradio.fun

[Bill Cox]

I like the orientation with the interface board between the connector from HL2 to N2ADR and the DB9 connector with jack screws.  I also like a simple 2-component LPF, if that is good enough for the analog outputs we need.  I think (haven't confirmed) that the RS2040 drives from 0 to 3.3V supply on GPIOs, so a simple LPF might be good enough.

I'd like to support additional expansion boards, maybe one oriented upside down on the top shell?  That makes it possible to mount power-fets on the top-side, if anyone really wants to try that.

If we have a single row of header pins on the inside edge of the interface board pointing up, similar to the HL2's header pins along the inside edge, it looks likely that they could be accessed from a female socket on an inverted expansion board mounted upside down in the top shell.  One of the most difficult assembly steps for me on the Hardrock-50 is the cabling between the upper and lower boards.  If we slide an expansion board into the upper shell, line up the socket with the header pins, and then press them together, assembly might be easier.  The other way expansion boards could use these pins would be to be mounted over the existing header pins, and use another HL2-N2ADR-like connector to the interface board.

73, Bill ak3q

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/32dc8f19-9e9f-8494-2229-45a6b5cf3b5d%40michvhf.com.

[J P Watters]

Bill,

Here is the N2ADR expansion header board that I fabricated for my HL2 units. It sits above the N2ADR filter board. 

If there was more board space, the next board could be layered with interconnections being the N2ADR board. We would then just have to increase the top of the 

Why couldn't the bottom side of this board be a ground plane? 

WIthout the any bands allocation above 10 meters to the upper limit of the HL2 (38mhz), why couldn't any tranverters use the 30mhz to 38Mhz for transverter frequency conversion. Could we then treat a Transveter just like another band below 28Mhz?

..jpw J P Watters

KC9KKO

Morris, IL USA

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CAOLP8p6LEkJ1et-MtQwP9SF7q5XezvhR1YmRBoJg2Zti%2B9yxjQ%40mail.gmail.com.

[Steve Haynal]

Hi Bill and Vince,

The full fan circuitry is overkill for the band voltage select. I think Matthew used it just because the circuit was already there. A LPF filter directly to the microcontroller pin should work, but maybe you want a little protection with an extra FET. Again, for those interested in band voltage select, it already exists in the stock gateware since last November:

https://github.com/softerhardware/Hermes-Lite2/wiki/Band-Volts

You just populate the fan circuitry and then select it with the dither control.

You can probably do some rough tests to see if just the DB9 and a board in the slot are rigid enough with the current back panel.

Four layer boards are not much more than two layer, and I suggest going with 4 layer to have a solid ground plane above the relays. I'm curious if such a ground plane will diminish the pickup of power supply spurs. I know aluminum foil over the switching regulators helps a little. See pdb shopper and jlc pcb:

https://pcbshopper.com/

When you are ready to have boards made and/or assembled, let me know and I will pay for it out of the R&D/repair funds.

Vince, what are you using for your PWM generator? A microcontroller? Which one? How are you sending data to it? Via i2c, USB or something else?

73,

Steve

kf7o

[Vince Vielhaber]

Steve, I'm using an Arduino Nano. My main need for it was selecting 1
of 6 relays on a Kenwood filter board for my cheap Chinese amp. Someone
on the 2+ list was asking about interfacing for the Xiegu amp that uses
CI-V. Taka suggested the 1st order LPF so I tried it and made sure all
the voltages needed were possible. I ended up incorporating it into the
software. Schematic and sketch are available on github:

https://github.com/michvhf/Hermes-Lite-2-Xiegu-interface

Vince - K8ZW.

On 10/12/2021 01:25 AM, Steve Haynal wrote:
>
> Vince, what are you using for your PWM generator? A microcontroller?
> Which one? How are you sending data to it? Via i2c, USB or something else?
>
> 73,
>
> Steve
> kf7o
>
>
>
> On Monday, October 11, 2021 at 10:04:51 PM UTC-7 jpwa...@gmail.com wrote:
>
> Bill,
>
> Here is the N2ADR expansion header board that I fabricated for my
> HL2 units. It sits above the N2ADR filter board.
> If there was more board space, the next board could be layered with
> interconnections being the N2ADR board. We would then just have to
> increase the top of the
>
> Why couldn't the bottom side of this board be a ground plane?
>
> WIthout the any bands allocation above 10 meters to the upper limit
> of the HL2 (38mhz), why couldn't any tranverters use the 30mhz to
> 38Mhz for transverter frequency conversion. Could we then treat a
> Transveter just like another band below 28Mhz?
>
> ..jpw J P Watters
> KC9KKO
> Morris, IL USA

> B2F6165D-38ED-49E1-B4B4-B0BBA2C39F45_1_105_c.jpeg

> <https://groups.google.com/d/msgid/hermes-lite/CAOLP8p6LEkJ1et-MtQwP9SF7q5XezvhR1YmRBoJg2Zti%2B9yxjQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> 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/95e1d5fd-c04e-4ba0-8c1a-d6f02279e02cn%40googlegroups.com
> <https://groups.google.com/d/msgid/hermes-lite/95e1d5fd-c04e-4ba0-8c1a-d6f02279e02cn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Steve Haynal]

Hi Vince,

Thanks for the details -- an Arduino Nano sketch to translate the FAXXXXXX uart HR50 frequency commands from the HL2 into Kenwood relay selection or band voltage selects.

73,

Steve

kf7o

[Bill Cox]

I've updated my strawman proposal.  I have two of the microcontroller boards that Steve linked to, but I think we should go with another on his list:

the SparkFun Pro Micro - RP2040.  It is $10, and Sparkfun has a limit of 100 per customer.  However, it fits easily in between the N2ADR connector and the backplate, has castellated pads so we can surface-mount it, and its USB port protrudes by 0.05".  The ItsyBitsy is simply not friendly for our application, lacking surface-mountable pads, and with the USB port flush to the board.  If we use the Raspberry Pico, we'd have to make the board even taller, since it 

I've simplified the strawman proposal.  The board would support band-voltage select, open-collector capability for PPT, have 3.3V GPIOs available on the DB9, and host USB 1.1.  There would be another micro USB connector to 5V IN.  The goal would be to have the bottom side be mostly a ground-plane, but I'll need to route some short jumpers on it to build the interface circuits.

With the Pro Micro the board can be shrunk a bit in height.  It would be about 0.2" taller than the N2DAR connector board, with height determined by the 0.7" Pro Micro board + 0.2 for its pads + 1.0" for the DB9, plus about 0.3" for the USB 5V IN.

Should it have perf-board holes for folks who need to customize their interface boards?  There is waaaay more space on the board than I need for the I/O circuits.

I'll start work on some schematics this week.

73, Bill ak3q

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/96f826ee-5f44-4418-9fb1-90444daa3a0bn%40googlegroups.com.

[Steve Haynal]

Hi Bill,

I read over the strawman proposal and it sounds good to me. The 51mm length of the pico is hard to work with! The Pro Micro RP2040 looks like a nice choice given it is only 33mm in length. It is also simple enough that we can easily move its components to your board if we start doing any significant production with Makerfabs. The pico is more widely available, but this board is available from www.sparkfun.com and Digikey. Do any international users anticipate problems sourcing a Pro Micro?

Having any extra be perf-board holes sounds good to me. It is easy to make and doesn't add to the cost. We should try to incorporate as many user IO requests as we reasonably and easily can.

Do you have any i2c client sketches up and running? You should be able to snoop the N2ADR band change messages. I am curious how easy that is to get going on the RP2040.

73,

Steve

kf7o

[Franz]

The Sparkfun Pro Micro RP2040 is available in Germany from www.distrelec.de for €12. Only 34 in stock at present. I have seen other places carry it at around €25. Not sure if there are other Sparkfun distributors here?

73,

Franz DO3PBE

[Sid Boyce]

Hi Steve,
I have just ordered one from thepihut.com UK.
73 ... Sid.

On 18/10/2021 02:52, Steve Haynal wrote:
> Hi Bill,
>
> I read over the strawman proposal and it sounds good to me. The 51mm
> length of the pico is hard to work with! The Pro Micro RP2040 looks
> like a nice choice given it is only 33mm in length. It is also simple
> enough that we can easily move its components to your board if we
> start doing any significant production with Makerfabs. The pico is
> more widely available, but this board is available from
> www.sparkfun.com and Digikey. Do any international users anticipate
> problems sourcing a Pro Micro?
>
> Having any extra be perf-board holes sounds good to me. It is easy to
> make and doesn't add to the cost. We should try to incorporate as many
> user IO requests as we reasonably and easily can.
>
> Do you have any i2c client sketches up and running? You should be able
> to snoop the N2ADR band change messages. I am curious how easy that is
> to get going on the RP2040.
>
> 73,
>
> Steve
> kf7o
>
>
>
>
> On Sunday, October 17, 2021 at 9:18:12 AM UTC-7 Bill Cox AK3Q wrote:
>
> I've updated my strawman proposal

> <https://docs.google.com/document/d/1ScB0PA7EqI4F6QLJzB3HjOlfG30MyimVmilTsn66G_c/edit?usp=sharing>. 

> I have two of the microcontroller boards that Steve linked to, but
> I think we should go with another on his list:
> the SparkFun Pro Micro - RP2040

> <https://www.sparkfun.com/products/18288>. It is $10, and Sparkfun

> <https://groups.google.com/d/msgid/hermes-lite/96f826ee-5f44-4418-9fb1-90444daa3a0bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> 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/1d93581b-2a77-4c8a-b2f2-32f379340870n%40googlegroups.com
> <https://groups.google.com/d/msgid/hermes-lite/1d93581b-2a77-4c8a-b2f2-32f379340870n%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

[Bill Cox]

I don't have I2C running, yet.  I've just ordered some 40-pin female headers from Mouser.  The one used on the N2ADR jumper is out of stock at Digikey, so I ordered something that looks similar from Mouser.  It should get here Wednesday.  The SparkFun Pro Micro RS2040 is ordered, but has not shipped, yet, but I can start with the Pico to try out I2C.

I would guestimate that at my current hobby level of hours, I'll be in prototyping / designing / board layout for maybe 6-ish weeks before ordering 3 boards from Osh Park, and a stencil from  Osh Stencils, and use a toaster oven to solder on the surface mount components.  So, maybe in about 9 or 10 weeks, I'll likely have a prototype working.  Is this fast enough?

73, Bill ak3q

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/Qsc7cpq7sv4/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/1d93581b-2a77-4c8a-b2f2-32f379340870n%40googlegroups.com.

[Steve Haynal]

Hi Bill,

That sounds great. This is a hobby for everyone so take your time. It was several years of design and prototyping before the first HL2 was out.

73,

Steve

kf7o

[Bill Cox]

I just put in a few hours learning about the RP2040 and researching available boards some more.  One thing I don't like about the Pro Micro RP2040 is that it uses a USB-C port, which cannot be used to host USB 1.1, AFAICT.  The USB-C spec has a legacy hack: If you ground the two new control pins with 5.1K ohm resistors, it treats you like a legacy USB device (not host), and does not try to negotiate anything.  The Pro Micro has the resistors to ground.  I also don't like the extra components we don't need.

So, I'm leaning towards building the new interface board with the RP2040 directly on it, instead of mounting a pre-made board.  I'm starting with the example design I found on Digikey: the RPi Pico Debugger Shoe.  So far, I've just ripped out parts we don't need, but haven't added any of our new interface stuff, yet.  The BOM so far is 28 parts, of which 10 are 0.1uF caps mostly for the RP2040 power pins.  This isn't too bad... I manually assembled plenty of my old Infinite Noise Multipliers, which have 25 parts on them.  I can manually assemble the first few boards, including the microcontroller related stuff.

I also ordered all the parts used so far, which was pretty easy since the original RPi Shoe had Digikey part numbers for all parts other than the RP2040.  BTW, the RP2040 is a $1 microcontroller.  It seems to be in stock in quantities we need at Chicago Electronic Distributors.  Lots of parts on the BOM are out of stock, but Digikey had good replacement parts that they auto-recommend for every one of them.

73 Bill ak3q

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/398bb118-4b04-4b31-86f8-6829bafe19cfn%40googlegroups.com.

[Bill Cox]

I have several design questions I'd like to work out related to the DB9 connector:

1) How should we connect the DB9 connector's pins in a flexible way to the interface board?

2) Should we by default use a straight-through DB9 connection, or crossover connection?

3) What should the programmable I/O circuits for the DB9 connector look like?

4) How many programmable I/O channels do we need?

5) How many D/A channels do we need?  More than 1 (for band select)?

6) Do we need any A/Ds connectable to any DB9 pins?

I'm leaning towards adding 9 jumpers to connect the interface board to the DB9, with a 2x9 header and 9 jumpers.  A good example of why jumpers are needed is the GND pin on the DB9.  If using a crossover cable vs straight-through, GND must be on either pin 1 or pin 5.  WIth 9 jumpers, folks wanting to hack the interface board can use the perf-board area to build their circuit, and jumper signals to the DB9 without cutting traces.  I'd probably add another jumper for connecting the band select voltage to the appropriate DB9 pin.

Should we use a female DB9 like I did in my version of the HL2-HR50 interface kit?  That required use of a crossover cable.  It has advantages, but does add a bit of complexity.  The alternative would be to go with Steve's original design using a male DB9 connector, and straight-through extender cables with one male and one female end.

What should the programmable I/Os look like?  The programmable digital I/Os, IIRC, roughly the following goals

- Support open-collector pull-downs, often used for PTT.  Can we assume the voltage is <= 18V nominally, and maybe design for 25V or so to have headroom?

- Support bi-directional 3.3V I/O, with high tolerance for abuse, e.g. grounding, tying to 5V, shorts between them, etc.  Be compatible with 5V pullup resistors (no diodes to 3.3V).

The open-collector feature is just mosfet.  The ability to drive 3.3V while tolerating at least an 18V pullup on the output is trickier.  To drive 3.3V well, it seems like we'd want a P-FET, but we'd need to tolerate the output being pulled much higher than 3.3V without sinking current.  Maybe a P-FET, with a resistor from the output to gate, and an open-drain N-FET from gate to GND?  That would be a total of 4 discretes per I/O channel seems like a lot.  Do we also need a ferrite bead?

We also need at least one (and maybe more?) A/D outputs.  Like many microcontrollers, the RP2040 has PWM outputs rather than A/D, but we can convert that to a voltage between 0V and 3.3V with a discrete low-pass filter.  Is a single-pole RC low-pass the way to go?  If we don't need level-shifting, are there reasons to go beyond a single-stage RC filter?

73 Bill ak3q

[Phil Theis]

Just a thought. If you are going to mount a connector like that, consider using the equivalent sized 15 pin (vga type) connector for expansion. Like we used back in the SDR-1000 and UCB days.

Phil K3TUF

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CAOLP8p73NWuR33%2BniaMMe3hUmBgL9uhjPRbvOmztnjDek06MKQ%40mail.gmail.com.

[Steve Haynal]

Hi Bill,

Great to hear about the progress and thought you are putting into this project. I don't have strong opinions about the DB-9. If anything, you might want to consider multiple connectors on the rear of the board. This may be easier to use if you have separate peripherals, like PA and/or ATU. Deciding what and how to add IO has always been difficult. There is just so many peripherals out there to consider. I am not a big peripheral user so think it is better to listen to those who do use many peripherals.

73,

Steve

kf7o

[Mark Wild]

Another connector thought.  How about extending the I2C out of the case using a Stemma/qwiic connector?  There are a lot of peripherals available that could just plug in and easily be coded. E.g. external relays, displays etc

Mark, G6DDX

[Steve Haynal]

Hi Mark and Bill,

If you run i2c any significant distance, take a look at how it is done in this design:

https://github.com/pressla/I2C-Bus-extender

73,

Steve

kf7o

[K7MDL]

I have started studying options to produce a 4 bit BCD output to feed to an external band decoder and/or multiband transverter.  I looked at PWM band voltages and the Serial port FA frequency messages but it appears they are FPGS created based on the TX frequency and therefore limited to 0-38.4 MHz of the HL2.   This does not work for VHF and above transverter band control.  That leaves building new i2c hardware interface boards, or doing something from the SDR host CPU itself (not desirable, breaks remote ops).

I would propose, if possible in protocol 1 (I have no idea), that an offset value be added taken from SDR app Xvtr tables.  The HL2 FPGA would then subtract the offset for the HL2 TX frequency, but pass on the original frequency value in the FA message.  Including the offset with another command would also be desirable.  There is one I have used for panadapter offset.  The FA command and serial output method already exists so no new hardware required.  

The value of this is that an outboard device (microcontroller) is free to decide what the intent of the user is for any possible frequency supported by the SDR app.  The receiving device would know what it's own capabilities are and imply the offset but a supplied offset value can also be used to set a programmable offset for "agile" transverter design.   Some of the new Kuhne microwave transverters give you the choice of several IF frequencies.  It is not a big step to make this configurable on the fly.  This leads to multiple transverters with multiple IFs mixed into the IF spectrum (0-38Mhz in this case).  

A separate uP on the i2c bus can also be made to do this, but it seems more efficient to have it come from the existing FA command.  This allows you to choose to keep the N2ADR filter board in if desired.  In my case I would normally leave it on 28Mhz for Transverter use then when I change to and HF band the transverters go offline (or standby) and the RF is switched to the HF antenna.  This achieves a DC to daylight solution with little fuss.  This is how I operate my K3 remote stations today. I have coverage on all bands from 1.8 to 1296MHz in a single radio and remote connection, the radio band decoder output commands all downstream automation and sequencing necessary.

A variation on this is to make usage 4 byte "Alex word" in protocol 2 that DL1YCF mentioned earlier.

As for the 4-bit output angle, I see that coming from i2c bus messages. Using the current state of code, you are forced to choose an interpretation of the J16 pins for HF or for VHF or SWL (in Thetis).  That means removing the N2ADR board for VHF use blocking HF usage. The advantage of this is existing apps only need to talk to a simple i2c port expander, it could be a 16 port version if the SDR apps are modified to use them. 

I see this interface board effort ending up allowing the N2ADR board to remain in the box and also be able to send a band decode value to a transverter for any band, or at least any frequency where the band is decided by the end device.  The frequency (and offset) can be sent on the existing serial port.  A uP on this interface board can choose to read and act on this information and produce a 4 to 8-bit BCD output (or a simple parallel output) to be used for multiple PTT outputs (some for amps, some for transverters, some for antennas, power detector switches.   VHF ops require multiple amplifiers and away to control them.

My use case is a HL2 remote located outdoors (in a box) alongside a Q5 Sigal 5-band transverter that covers all 5 VHF bands 144-1296MHz at up to 80W out in a single compact box about 11 inches square.  Only ethernet and power are required from the ground.  Leaving the box are only antenna cables.  With a multiband LPDA like I use, only 3 cables for HF, 6M, 144-1296.  This box is easily moved from the fixes station to a portable or mobile operation in minutes, no mass of cabling and related failure risks, no long setup times.  Simple, small, portable, and helps keep our friend Murphy at bay.

- Mike

K7MDL

[K7MDL]

I would like to add to my use case comment.

"My use case is a HL2 remote located outdoors (in a box) alongside a Q5 Signal 5-band transverter that covers all 5 VHF bands 144-1296MHz at up to 80W out in a single compact box about 11 inches square.  Only ethernet and power are required from the ground.  Leaving the box are only antenna cables.  With a multiband LPDA like I use, only 3 cables for HF, 6M, 144-1296.  This box is easily moved from the fixes station to a portable or mobile operation in minutes, no mass of cabling and related failure risks, no long setup times.  Simple, small, portable, and helps keep our friend Murphy at bay."

The setup described above exists today in my stations, except the HL2 in this story is currently a K3, located in the shack, cab of a truck, or in a RV.   

The Q5 5-Band transverter requires a 4-bit BCD input, which the K3, K2, several Yaesu and some other radios natively supply.  I built an Arduino RF power meter + band decoder that takes care of all the downstream stuff including the transverter using the BCD output from the radio.  To use a HL2 in the K3's place, I need to supply the equivalent 4-bit BCD.  This is best delivered from the HL2 itself so only ethernet cable is required now for complete seamless control.

[Steve Haynal]

Hi Mike,

The FPGA RTL to change to do this is at:

https://github.com/softerhardware/Hermes-Lite2/blob/master/gateware/rtl/extamp.v

73,

Steve

kf7o

[Mike Lewis]

The FPGA code is not in my wheelhouse but I can make out good chunk of it, still questions remain. 

 

I went searching around the rest of the FPGA code and also the Protocol 1 specs. The specs were hard to find.  I found an Ozy USB spec V1.57 document which I think the ethernet version was a adaption of that and close to the same. 

 

I see the only frequency related fields in protocol 1 are for 1 TX NCO value and up to 7 RX NCOs values.  No place for IF or LO frequencies without repurposing a field here or there.  For transverter band decoder support from the HL2 itself some changes are required in the SDR app and/or HL2.   The question is where best.

 

Question or validations:

1. In the rtl code Control.v the FPGA receives the tx_freq from the SDR app and it looks like it is passed unaltered to extamp() and then output to the FPGA serial port. 
1. I see no validations or restricting on the values getting to here other than fitting in 4 bytes.
2. I see no restrictions on the output frequency sent.
3. The frequency values seen here are limited to what the SDR app sends.
4. The frequency may be outside the usable range of the hardware (ADC, USC and clocks) resulting in a non-working receiver/transmitter, but the serial port value will be there regardless.
2. Are the Alex band filter bits (Band value and enable/disable bit) used in any way in the HL2 FPGA today?   Especially if the N2ADR board is used?  I assume they are unused on the HL2.
3. Looking in Control.v file I see how the Band Voltage is created. It looks like the raw frequency sent by the SDR app is compared to a hard coded table set for HF bands only.  As is, it is not useful for transverter band indication. Maybe we can find a way to signal this code to use an alternate table for 50MHz and higher bands. 
4. Are there unused Protocol 1 fields suitable for repurposing to communicate LO frequency sent to the FPGA by the SDR app?

 

Since the Hl2 is limited to HF bands there needs to be a way to add some offset to the dial frequency it receives.  Maybe it is simply having the SDR app stuff the LO frequency into an ??unused?? field like the Alex fields (2 bytes long, possible bits from the prior field also) and the FPGA uses the result of freq – LO.  The i2c N2ADR can work as normal including being selected to the right IF band.  I have some alternative ideas percolating but are more complicated.

 

Mike

K7MDL  EL87sm & CN88sf

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/6c5a7eb9-f868-4123-930a-62e325f0dd7en%40googlegroups.com.

[Steve Haynal]

Hi Mike,

Did you see the protocol wiki page?

https://github.com/softerhardware/Hermes-Lite2/wiki/Protocol

The links for the two relevant documents are at the top of that page. This is where we document extensions to the protocol. You can see here how some extensions are done.

73,

Steve

kf7o

[Mike Lewis]

Totally missed that entry.   Reading that page it seems the Alex bits are used and can be split and used BCD-like or other combos as agreed for use in the SDR apps. I have seen the split option in apps like Thetis but that would interfere with the N2ADR board so I count that out.   If a revision or hand modification to the N2ADR board used the MCP23017 16 port expander, that would be a convenient option to provide some auxiliary IO lines.

 

As of today, for transverter work with dial frequencies above 28MHz (collectively called VHF+), the Band Voltage and HL2 serial port are not usable.

 

Unless we can add a new extension for LO frequency (so Dial Freq = LO + IF), it seems like the best option left is the i2c approach.  The SDR continues to send the IF frequency only down to the HL2.  The i2c bus needs to carry the dial frequency, LO frequency, and/or VHF+ band info.  If a uP is used on the i2c bus it can offer a serial port output with the dial frequency in place of the built in serial port and/or IO pins. To keep the N2ADR filter board (desirable) then a port expander or uP must be at a new address.  I was hopeful there was a way the FPGA serial port could be leveraged and not require any new external hardware ;-(.  

 

Please carry on with your regularly scheduled programming!

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/cc6e6596-63da-4ca4-917f-330f554d32ben%40googlegroups.com.

[James Ahlstrom]

Hello Group,

What is the status of adding an MCU to the HL2? I have re-read this thread and there are a lot of good ideas here. Is the project active?

If it is not too late, I have some additional ideas. Several have requested a separate Rf input and a dedicated Pure Signal input. These would have to go to RF3 on the HL2. But that is in parallel with the antenna input RF2 through the T/R relay. So I suggest we use a FET to ground INTTR to switch the T/R relay to Tx even for receive. Then RF3 becomes the Rx input. There would be additional RF switches to select the source and disconnect RF3 for normal T/R operation. I also think we need a switchable HPF on RF3 to replace the one on the N2ADR filter board.

Jim

N2ADR

[si...@sdr-radio.com]

Jim,

 

Any solution which provides a separate RX antenna will be fantastic. Pure Signal feedback good but the HL2 is clean as it is.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of James Ahlstrom
Sent: 12 January 2022 18:05
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Discussion of next-gen HL2 interface board

 

Hello Group,

--

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/daf2b081-863b-4c20-9e97-9920c82ef7d8n%40googlegroups.com.

["Christoph v. Wüllen"]

Upon TX, you have to ground the "RX side" of the TRX relais
without grounding the RF input. Grounding is a measure against
relay crosstalk. So in principle one needs two relais:

- one switches the receiver between TRX relais and PS feedback input
- one grounds RX side of TRX relais during TX

Whether this can be done super-linear with FETs I do not know.

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/026e01d808a3%24e7273ef0%24b575bcd0%24%40sdr-radio.com.

[James Ahlstrom]

Yes, crosstalk through any relays or switches is a problem. But the design goal is to have no changes to the HL2 board so that current owners can use it. So we will have to make an IO board and see how bad the crosstalk is.

Jim

N2ADR

[Harry Large]

Hello is there any information when the HL2 will be available for purchase.

Harry

KB4HL

On Friday, October 1, 2021 at 4:03:36 PM UTC-5 Bill Cox AK3Q wrote:

IIUC, Steve would prefer for design discussions to happen on the list, rather than private emails.  I'd like to see if we can come to a consensus on what we want the interface card to do, and roughly the architecture.  Currently, a number of folks on this list know far more about this than me, so I hope you all will educate me.  I'd like to design this for the group, and get it fabbed, if no one else is already doing it.  I'll take whatever help is offered.

Interface to the interface board

I'm leaning towards making it a "hat" that floats either above the DB1 or DB7 connector.  Both give access to the I2C bus, which so far sounds like the right bus for the interface board to live on.  DB7 has access to the signal that keys the external amp, EXTR.  DB1 has access to the FPGA's UART.  However, the FPGA could send us band-change info (currently on the UART) and tell us that the amp is being keyed over the I2C bus, IIUC.  The choice of DB1 or DB7 probably depends on the functionality we want for the interface board.

Interface between HL2 and other open-hardware devices

We might be able to modify open-hardware designs to be compatible with our preferred interface, rather than having HL2 attempt to support lots of open-hardware interfaces.  What would our prefered interface be?  Would it be similar to our UART based interface to the Hardrock50, which allows an HL2 to control only 1 peripheral, or should it be more like USB or I2C which could allow a single HL2 to control multiple peripherals?

Currently, the HL2 -> HR50 interface board uses 3.3V UART signaling, which is understood by the Hardrock50, and probably a lot of other devices.  However, the Hardrock50 also has USB, as do many other peripherals.  Is USB an option?  Usually USB with a fairly complex driver, but we don't have a CPU in HL2.  I don't know if we can afford a USB master in the gateware.  On the positive side, a single USB master could support any number of peripherals, whereas UART supports only 1.  Here's a simple-ish USB host core using ~400 registers and LUTS.  Are we this constrained on the FPGA?

Using I2C signalling, amplified to 12V with bidirectional bus drivers was suggested as an option.  I'm not sure how to assign different devices different addresses on an I2C bus when peripherals can be mixed and matched.  Was this scheme meant to work with multiple peripherals on the same 12V I2C bus?  Cool if so, also a bit scary.

One concern with 3.3V UART is that the current UART to the Hardrock50 is glitchy when the Hardroc50 is transmitting.  Some ham radio equipment uses opto-couplers, or digital-isolators.  Should we support digital isolators or opto-couplers?

Supporting various commercial devices

The interface to varios radios and power amps seems to be all over the map, which is why we want a microcontroller on the interface board.  What features are required to support a broad set of commercial interfaces?  For instance:

• What voltage ranges are needed?
• Do we need an A/D or D/A?
• How many I/Os do we need?  Are 9 enough?
• Do many require USB?
• Do many require UARTs?
• How could we support opto-couplers/digital-isolators?

What microcontroller should we use?

I'd love to use RISC-V based microcontrollers, but cheap RISC-V microcontrollers are not yet available.  Some questions:

• Can we use an ARM based microcontroller?
• How do we keep noise from the microcontroller from interfering with the radio?
• What peripherals do we need?
• How many I/Os?

Feel free to post any ideas/thoughts.

73, Bill ak3q

[James Ahlstrom]

Hello Group,

I seems this project needs a Mom so I have started work on it. I apologize if anyone is currently working on this. If you have a board, please let us know.

I roughed out a PCB, but I don't really like it so I will have another go. The main features are:

A PCB about the size of the N2ADR filter board that connects to the 2x20 header and to through-hole connectors on the back plate.

An SMA for a separate Rx input and another for Pure Signal. Most other connectors will need to go through-hole on the back plate and be wired to the IO board.

A switchable HPF like the filter board.

A 5 volt linear regulator.

A Raspberry Pi Pico soldered to the board. All its IO is 3.3 volt. All unused pins are available.

Eight Pico GPIO pins go to a 5 volt level shifter, and then to open drain MOSFETs. So you can have 5 volt logic and low-side relay drivers.

P82B95 chip to extend the I2C bus.

Two UARTs and an interface chip to generate correct +/- 7 volt levels.

Two PWM channels, filters and op amp drivers to create band-switch control volts.

The fan control and antenna tuner from the back plane. This is controlled by the Pico, not the FPGA.

A small bare copper prototype area. Through holes are incompatible with most chips. So "dead bug".

The objective is to accommodate all current HL2's and the new HL2.1 with the same IO hardware board and HL2 gateware. And no configure bits.

Another objective is no changes to SDR software (Quisk, Spark, linHPSDR, etc.). Use the current filter bits (if possible).

The only change to the HL2 board is a three pin header to pick up VSUP.

Also, no changes to the gateware if possible. OK, hardly any. And only one gateware version for HL2 with or without the IO board.

This is an early look so things can change. I won't know how realistic this is until I can make and test a board. I did check the Pico running the Blink program and saw no noise when close to the HL2 filter board.

Jim

N2ADR

[Steve Haynal]

Hi Jim,

Thanks for offering to adopt this project. Your list looks pretty good to me. Other users with more IO needs than me will probably chime in. 

I don't know if you have a MCU in mind, but I recently saw that the RP2040, which was only $1, is now discounted in volume. It is also readily available.

https://www.zdnet.com/article/now-you-can-by-giant-reels-of-raspberry-pis-rp2040-chips/

73,

Steve

kf7o

[Michael Durkin]

If i2c or other can be used to pass frequency information, 6m-vhf-uhf, and ptt. That's a starting point to work apon. 

The hl2 is an hf radio and a transverter board is about the only option. 

Ok1dx seems to have progress in this realm. A lower power xvtr 500mW in the case seems doable. I have used stripline bandpass filters for VHF/UHF

Seen this as a draft -- thought i sent it awhile ago ...

Is there a place to snoop i2c on the HL2 ... I have quite a few arduino boards that i can try and set up a sketch to output all rx'd i2c to a serial port

Mike KC7NOA

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/0e9d6992-9f14-42bd-859c-77a148c1e6c7n%40googlegroups.com.

[radi...@mail.com]

Just to chime in from a user perspective (sorry I don't have the knowledge to fully understand all the tech implications), and apologies in advance if I missed something from the previous posts in this thread, but my dream HL2 switching/filter facility would be ability to have HL2 in enclosure with Jim's current N2ADR style board for HF use, and also some sort of multiple internal switching to feed up to maybe three of Matthew M5EVT's HL2 companion transverters in the same enclosure (for example 6m/2m/70cm), so basically a multiband HF/VHF/UHF HL2 could be self-contained in a slightly larger than standard case without the need for some sort of external switch box as is currently the case. Switching would (perhaps?) also power/de-power the relevant transverter to keep spurious RF levels down inside the case? 

On the other hand perhaps people see the main route being as described by Mike K7MDL in his earlier post i.e. inputs/outputs to drive outboard multiband transverter but my idea is for a more affordable transverter/multiband option offered by Matthew's modules much more aligned to the idea and cost of the HL2 project itself. For example, Q5 Signal's multiband transverter is $2000 and does not even offer 50MHz. Maybe I'm alone, but I'd certainly purchase multiple of Matthew's transverter cards in common bands if available on Makerfabs (or self-build of course), so HL2 becomes a complete modular HF/VHF/UHF project? Low power drives out to feed block LDMOS amps for each band?

73, Max

[Roger David Powers]

Correct me if I'm wrong, but Jim's email says "A Raspberry Pi Pico soldered to the board" whereas Wikipedia says:

The RP2040 is a 32-bit dual ARM Cortex-M0+ microcontroller integrated circuit by Raspberry Pi Foundation.^[1][2][3] At the same time, it was released as part of the Raspberry Pi Pico board.^[1]"

And:

^{The Pico has 264 KB of RAM and 2 MB of flash memory}

So it seems he is planning to include a RP2040 in the form of a Pico board rather than putting down these components individually.

Regards,
RDP

--

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/c9b0814f-2156-4339-ab6a-bbf8472e248en%40googlegroups.com

.

[Vince Vielhaber]

The RP2040 is the micro used on the RPi Pico. The pico costs about $4
USD whereas the PR2040 by itself is under $1 USD in quantity and about
$1 in singles.

Vince.

On 01/20/2022 04:13 PM, 'Roger David Powers' via Hermes-Lite wrote:
> Correct me if I'm wrong, but Jim's email says "A Raspberry Pi Pico
> soldered to the board" whereas Wikipedia says:
>

> The *RP2040* is a 32-bit
> <https://en.wikipedia.org/wiki/32-bit_computing> dual
> <https://en.wikipedia.org/wiki/Multi-core_processor> ARM Cortex-M0+
> <https://en.wikipedia.org/wiki/ARM_Cortex-M0%2B> microcontroller
> <https://en.wikipedia.org/wiki/Microcontroller> integrated circuit
> <https://en.wikipedia.org/wiki/Integrated_circuit> by Raspberry Pi
> Foundation
> <https://en.wikipedia.org/wiki/Raspberry_Pi_Foundation>.^[1]
> <https://en.wikipedia.org/wiki/RP2040#cite_note-2021-01-21-RP2040-announcement-1>
> ^[2]
> <https://en.wikipedia.org/wiki/RP2040#cite_note-2021-02-01-arm-blog-2>
> ^[3]
> <https://en.wikipedia.org/wiki/RP2040#cite_note-2021-RP2040-datasheet-3>

> At the same time, it was released as part of the Raspberry Pi Pico

> <https://en.wikipedia.org/wiki/Raspberry_Pi#Raspberry_Pi_Pico> board.^[1]
> <https://en.wikipedia.org/wiki/RP2040#cite_note-2021-01-21-RP2040-announcement-1>"
>
>
> ^
>
> And:
>
> ^
> ^The Pico has 264 KB of RAM and 2 MB of flash memory
> <https://en.wikipedia.org/wiki/Flash_memory>

> *A Raspberry Pi Pico soldered to the board. *All its IO is 3.3 volt.

> <mailto:hermes-lite...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/hermes-lite/c9b0814f-2156-4339-ab6a-bbf8472e248en%40googlegroups.com

> <https://groups.google.com/d/msgid/hermes-lite/c9b0814f-2156-4339-ab6a-bbf8472e248en%40googlegroups.com?utm_medium=email&utm_source=footer>
> .

>
> --
> 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/1124301079.772527.1642713212443%40mail.yahoo.com
> <https://groups.google.com/d/msgid/hermes-lite/1124301079.772527.1642713212443%40mail.yahoo.com?utm_medium=email&utm_source=footer>.

[James Ahlstrom]

I am in New Mexico skiing but I have been working on this at night. I want to start with the hardware and ask all IO Board users whether these features are sufficient. There is an SMA for Rx input and another for Pure Signal as before. There is a male DB9 on the back. The nine pins have these features controllable from software:

One switchable 12 volt (VSUP)

One switchable 5 volt at modest current from a linear reg

One ground

Five combination LSS and 5 volt cmos

One FT-817 band voltage

LSS means low side switch, a Mosfet to ground for switching relays. The cmos inputs are protected and work from 3 volts to 20. The cmos outputs are 5 volts.

As an example you could use two cmos for RS232, but only the 0/5 volt version used by MCUs. You could add RTS and CTS with two more. Or you could have 5 bit data or switch five relays. The AH4 tuner is controlled by the 12 volt pin plus one cmos input for the KEY line. The LSS can control wired-or buses such as I2C and one-wire.

Software comes later but for now think about the power amps and peripherals you have and make sure these connections work. If you need anything more please let me know.

Jim

N2ADR

[Bill Cox]

I'm sorry I haven't been keeping up lately.  It was already crazy and then it got worse.  I'm already working nights and weekends and now we have to move again because we're being kicked out of our current house.  It may be a few months before I can play with my radio equipment again.

[Steve Haynal]

Hi Bill,

Thanks for the update. I hope your life settles down soon!

73,

Steve

kf7o

[neiljw...@gmail.com]

Hi Jim, thanks for looking at this project.

My needs look to be met by this setup.

I would use all 5 data bits, with one to select between HF and transverters and the other 4 bits to select the band.

This gives 15 possible bands on HF and 15 transverter bands (I have 9 transverters for bands to 10GHz)

assuming the 4-bit value of 0 selects nothing.

The RX input SMA is perfect to take RX from the transverter as I do now.

I am suspicious of the FT-817 band voltage approach in case of RF coupling to the voltage, but understand it

is used successfully by others and is supported by some amplifiers.

Hope this helps, 

Neil  G4BRK

[James Ahlstrom]

Thanks for the comments, the first I have received! There is the problem of sending the band to the HL2. I was thinking that the IO board would be considered a different filter board with different bits assigned in the SDR software. Bands would have standard numbers 0 to 127. The IO board would then send the correct bit pattern to the N2ADR filter board for  the HF bands. That way no SDR author would have to change their software.

I am struggling to assign pins to the DB9. I think the only solution is to require each user to solder jumpers from the IO board pads to the DB9 pins in the pattern they need. I was hoping to do this in software, but that is hard.

Jim

N2ADR

[Alan Hopper]

Hi Jim,

this may well be covered but I I'll throw it in the pot anyway as I'm not sure I have the full picture:- for skimming and other types of multiband receive it is great to be able to open up any possible combination of holes/blocks in the spectrum that a filter set allows, the current N2ADR/HL2 setup allows this allows this and Spark makes use of it.

73 Alan M0NNB

[James Ahlstrom]

Hello Group,

Here is the status of the IO board. I ran out of IO pins so I needed to make some compromises. There are eight low side switches (MOSFET to ground) and eight 5 volt logic outputs, but they are driven by the same MCU pin. . So you can have 3 logic and 5 switched, 4 and 4 etc. One of the logic outputs has a filter for PWM. There are five logic inputs that work from 3 to 20 volts. There are also RF switches, switched 5 and 12 volts and a fan output.

The only connectors are two SMAs and a DB9. You must solder jumper wires from the DB9 to whatever IO board resources you need. For example, a serial line would need one ground, a 5 volt output for Tx and an input for Rx. The problem is that the DB9 connections are not standard, and most amps don't even have a DB9. You must also install firmware that knows how to talk to your amp or transverter.

All SDR software (Quisk, Spark, linHPSDR, etc.) will need to be modified to use the IO board. The minimum would be to send the standard band number to the board with I2C. Then the firmware on the board would do whatever the connected amp needs. Steve offered to send the data the HL2 gets to the IO board, but that is not sufficient. Only the PC knows if the HL2 is on 10 meters because it is really using 10 meters or because it is on two meters with a transverter.

The prototyping area is rather small so I added pin headers so a perf board could be plugged in for extra customization.

I will not be using this IO board because my shack is controlled by a bus connected directly to the PC. But people want to use the HL2 to pass information through to peripherals. That means I can not test the IO board. I must depend on each user of (say) a HardRock 50 to tell me if the hardware and software works. The same for transverters. I can then make any needed changes.

If you want modifications please let me know now before I start ordering boards.

Jim
N2ADR

[si...@sdr-radio.com]

Hi,

 

Would software know whether there is a next Gen interface board connected?

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of James Ahlstrom
Sent: 16 February 2022 16:52
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Discussion of next-gen HL2 interface board

 

Hello Group,

--

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/451a5982-7e69-4c46-b15e-4554340a8bd2n%40googlegroups.com.

[Reid Campbell]

Hi James,

Sorry for coming to this late but I have a few suggestions which you might include which have been mulling in my head.

Go for 3 RF inputs, Pure Signal, Transverter & Rx antenna. The inputs should be general purpose so if somebody wanted two Rx aerials, they could use the transverter port. The HPSDR protocol allows for 3 external Rx/transverter inputs.

Add the capability to have LPF/BPF/HPF in the RF input lines. This would allow filtering of the Rx antennas or experimentation with undersampling. The PS input could use the pads for an attenuator. Zero ohm the pads out if not needed.

Provide for uFL pads for the switched RF inputs with zero ohm link to break the normal path. This would allow connection to the AD9866 RF input for under-sampling experimentation.  

Consider two 9 pin D connectors to separate input/output for different equipment. Ok, so 3 RF and two D on the back might be pushing it but maybe go to a 15 D, normal or hi density 9 pin. 

Consider increasing the size of the IO board to include the other side of the DB7 connector. This would help to move any of the RF noisy elements away from the signal chains. Some would be concerned about limiting air flow over the PA but a cut out could be added to mount a small fan in the PA area to direct air directly onto it.  The physical stability of the board could be enhanced by picking up some of the other headers on that side of the DB7 connector.

I would be interested in seeing you circuit when you have completed it. What are you using to switch the RF?

Cheers

Reid
Mi0BOT/Gi8TME

--
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/451a5982-7e69-4c46-b15e-4554340a8bd2n%40googlegroups.com.

[si...@sdr-radio.com]

3 RF Inputs as below would be ideal.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of Reid Campbell
Sent: 17 February 2022 09:21
To: herme...@googlegroups.com
Subject: Re: Discussion of next-gen HL2 interface board

 

Hi James,

[James Ahlstrom]

Hello Simon,

Yes, the IO board has a chip on the I2C bus with the hardware version number. Just read the bus at its address. The version is 1, and if there are subsequent boards with different hardware the version number will be different. Note that this is independent of any software on the MCU.

Jim

N2ADR

[si...@sdr-radio.com]

Thanks.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of James Ahlstrom
Sent: 17 February 2022 13:15
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Discussion of next-gen HL2 interface board

 

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/fb3fe079-d327-4cc1-8264-879497b2d870n%40googlegroups.com.

[Keith Hornbaker]

Wondering if it would be reasonable to request adding a second HL2 case creating a board to replace the current filter board (save for reuse) the new board would be an option selector (I2C based?) and current signals router. Create a new pcb for the new case same size as the current HL2 pcb and a plug for the current filter board maintaining current capabilities if needed. The new pcb in the second case could also be populated with MCU(s) to capture the selection signals from the option selector. 

[Mike Lewis]

New added custom i2c messages added to SDR apps that pass dial frequency and offset?  Can leave the existing band i2c messages as is.  Then tables in the io board can determine what to do with the frequency/LO data, such as translate to band bits, or do nothing and simply pass them on over serial.

 

Mike

K7MDL  EL87sm & CN88sf

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of James Ahlstrom
Sent: Tuesday, February 15, 2022 17:42
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Discussion of next-gen HL2 interface board

 

Hello Alan,

 

Sorry for the long delay.  I think I need to leave the filter board bits alone so you can switch filters without having to write special software. So you can just continue doing what you are doing now.  I will figure out some other way of sending extended information.

 

Jim

N2ADR

--

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/6597fd47-8fd8-40ee-b625-55302147b045n%40googlegroups.com.

[James Ahlstrom]

Hello Reid,

I don't think any of the RF changes can be made on the current IO board. I am already worried that stray RF pickup will overwhelm the ADC and adding more paths would only make this worse. The correct place for this is the HL2.1 board. There are already uFL connectors there but the switching would have to be added. The current HL2 has an anti alias filter that prevents under-sampling, but you could remove it. Also, the back panel barely fits two SMAs, a DB9 and the Pico.

I am switching the RF path with MASWSS0179TR-3000.

Jim

N2ADR