Filter Control Discussion Alex or J16 or both...
352 views
Skip to first unread message
John Williams
Jan 20, 2015, 11:56:35 AM1/20/15
to herme...@googlegroups.com
As I peruse the various software options we have for Hermes Lite, 2 key features of HPSDR come to light. There is the ability to configure Alex, which gives a set of filter and control options that are aligned with the Alex control protocol that I have discussed in prior threads. Today I started testing with Power SDR and see that there is a separate, free standing J16 capability for control of filters called Hermes Control. In order to remain upstream software compatible, we have some decisions to make.
For Alex, we have CN3 on the 1.21 board. This is intended to implement the SPI protocol for TX strobe and RX strobe at a minimum. That will allow the current Megaboard design to be controlled. If we deem that too complex, I could change the design of Megaboard to use the J16 protocol. I need input on this. I am nearing completion of the board design. To implement the SPI protocol in rtl I am guessing is not a trivial exercise. Using J16 would simplify the Megaboard design and reduce parts count.
J16 should be implemented for sure. For J16, we should assign a set of GPIO pins to align with the 7 bits of transmit and 7 bits of receive control. This would allow existing J16 capable designs to work. If we use GPIO0 for one of the TX pins, we can then control the Superband PA board within this capability. (of course I could change pin assignments in a future revision if needed). Thus, no separate mechanism to control the superband board will be necessary. The way I read it, J16 band assignments are changed as bands are selected, and then kept relatively static.
Thoughts?
Graeme, are you monitoring?
Sid - is there any background on why J16 was invented for Hermes vs. Alex?
John - AC9HY
For Alex, we have CN3 on the 1.21 board. This is intended to implement the SPI protocol for TX strobe and RX strobe at a minimum. That will allow the current Megaboard design to be controlled. If we deem that too complex, I could change the design of Megaboard to use the J16 protocol. I need input on this. I am nearing completion of the board design. To implement the SPI protocol in rtl I am guessing is not a trivial exercise. Using J16 would simplify the Megaboard design and reduce parts count.
J16 should be implemented for sure. For J16, we should assign a set of GPIO pins to align with the 7 bits of transmit and 7 bits of receive control. This would allow existing J16 capable designs to work. If we use GPIO0 for one of the TX pins, we can then control the Superband PA board within this capability. (of course I could change pin assignments in a future revision if needed). Thus, no separate mechanism to control the superband board will be necessary. The way I read it, J16 band assignments are changed as bands are selected, and then kept relatively static.
Thoughts?
Graeme, are you monitoring?
Sid - is there any background on why J16 was invented for Hermes vs. Alex?
John - AC9HY
John Williams
Jan 20, 2015, 12:50:51 PM1/20/15
to herme...@googlegroups.com
Steve,
How much of these protocols are contained in the rtl code you ported from Hermes? Is there code there that is stubbed off?
John
How much of these protocols are contained in the rtl code you ported from Hermes? Is there code there that is stubbed off?
John
--
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.
For more options, visit https://groups.google.com/d/optout.
John Williams
Jan 20, 2015, 3:17:14 PM1/20/15
to herme...@googlegroups.com
Looking more at the Hermes schematic, I am leaning towards support of both protocols, just as they do. Pls comment.
Zl2APV
Jan 20, 2015, 4:55:54 PM1/20/15
to herme...@googlegroups.com
Hi John,
Just got back yesterday so no time to do anything yet. I am not sure what J16 is and would appreciate a reference to read up about it. My experience has been with Modbus, I2C and SPI. These have been in the context of controlling machinery with a PIC microprocessor. My preference has always been for I2C as Modbus is more complicated and SPI needs extra outputs for each device to be controlled rather than running an address over the bus but it is the simplest.
73, Graeme ZL2APV
Just got back yesterday so no time to do anything yet. I am not sure what J16 is and would appreciate a reference to read up about it. My experience has been with Modbus, I2C and SPI. These have been in the context of controlling machinery with a PIC microprocessor. My preference has always been for I2C as Modbus is more complicated and SPI needs extra outputs for each device to be controlled rather than running an address over the bus but it is the simplest.
73, Graeme ZL2APV
Sid Boyce
Jan 20, 2015, 7:37:01 PM1/20/15
to herme...@googlegroups.com
Hi John,
I have no firm information but I would think that J16's open collector design was intended to accommodate alternative PA's with built-in LPF's and SPI to support Alex.
Attachments for the Quadra Amplifier and the scheme adapted for the eb104.ru separate BPF and PA/LPF boards.
73 ... Sid.
I have no firm information but I would think that J16's open collector design was intended to accommodate alternative PA's with built-in LPF's and SPI to support Alex.
Attachments for the Quadra Amplifier and the scheme adapted for the eb104.ru separate BPF and PA/LPF boards.
73 ... Sid.
--
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.
For more options, visit https://groups.google.com/d/optout.
-- 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
Sid Boyce
Jan 20, 2015, 8:02:10 PM1/20/15
to herme...@googlegroups.com
I don't know if they are in the FPGA
code as they have to be configured in PSDR, cuSDR, KissKonsole,
g0orx.openhpsdr and ghpsdr3-alex (latest code merged into the
master branch yesterday by Andrea) - trunk/src/server - server.c,
ozy.c and ozy.h and introduces a "--j16" option.
"hpsdr-server --hermes 255 --j16 --samplerate 192000 --interface eth0" tested by me several days before the merge.
Identical settings for PSDR, KissKonsole, g0orx.openhpsdr and cuSDR.
73 ... Sid.
"hpsdr-server --hermes 255 --j16 --samplerate 192000 --interface eth0" tested by me several days before the merge.
Identical settings for PSDR, KissKonsole, g0orx.openhpsdr and cuSDR.
73 ... Sid.
On 20/01/15 17:51, John Williams wrote:
Steve,
How much of these protocols are contained in the rtl code you ported from Hermes? Is there code there that is stubbed off?
John
On 1/20/2015 10:56 AM, John Williams wrote:
As I peruse the various software options we have for Hermes Lite, 2 key features of HPSDR come to light. There is the ability to configure Alex, which gives a set of filter and control options that are aligned with the Alex control protocol that I have discussed in prior threads. Today I started testing with Power SDR and see that there is a separate, free standing J16 capability for control of filters called Hermes Control. In order to remain upstream software compatible, we have some decisions to make.
For Alex, we have CN3 on the 1.21 board. This is intended to implement the SPI protocol for TX strobe and RX strobe at a minimum. That will allow the current Megaboard design to be controlled. If we deem that too complex, I could change the design of Megaboard to use the J16 protocol. I need input on this. I am nearing completion of the board design. To implement the SPI protocol in rtl I am guessing is not a trivial exercise. Using J16 would simplify the Megaboard design and reduce parts count.
J16 should be implemented for sure. For J16, we should assign a set of GPIO pins to align with the 7 bits of transmit and 7 bits of receive control. This would allow existing J16 capable designs to work. If we use GPIO0 for one of the TX pins, we can then control the Superband PA board within this capability. (of course I could change pin assignments in a future revision if needed). Thus, no separate mechanism to control the superband board will be necessary. The way I read it, J16 band assignments are changed as bands are selected, and then kept relatively static.Â
Thoughts?
Graeme, are you monitoring?
Sid - is there any background on why J16 was invented for Hermes vs. Alex?
John - AC9HY
--
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.
For more options, visit https://groups.google.com/d/optout.
--
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.
For more options, visit https://groups.google.com/d/optout.
John Williams
Jan 20, 2015, 9:57:46 PM1/20/15
to herme...@googlegroups.com
Graeme and Sid,
My observation is that Hermes implemented multiple external control protocols to appease multiple constituencies over time. Alex precedes J16 as I read it and is a well thought out, all encompassing multiplexing protocol, originally implemented prior to Hermes. It uses SPI and 2 strobes to latch (at the filters) state for both RX and TX needs, using 4 shift registers and buffers. State is maintained and as registers are written, prior data settings are preserved. They use it for RX and TX filter control, attenuation, preamp, XVTR, PTT and antenna switching. I have found an implementation that takes the protocol and creates a interface to allow the use of external LPFs (external meaning non-hpsdr alex hardware) with Hermes. I like theAlex protocol and implemented it for the 160M-10M PA ( Graeme - we are calling it Megaband hihi).
J16 is the connector on Hermes, that provides a cornucopia of function to external components. Part of which is a set of 7 open collector outputs, plus PTT, to control LPFs/BPFs. State is maintained in the application, not the FPGA (I think), and most of the hardware/firmware is a pass-thru. The manipulation of those bits of data is defined in a config screen in the radio application. You can use one bit per filter, or BCD or anything else that makes sense to the sender and the receiver. When transmitting, it sends the TX 7 bits, when receiving, it sends the RX 7 bits. It is pragmatic and to the point. Gives you what you need and none of the fluff. This would make the Megaband card itself simpler and lower parts count. it would not be as extendable.
J16 is described in the Hermes user doc. The other docs are self explanatory. Alex alternate is good in that it shows the logic required to implement the 16 bits of latched state. Sid's docs show the simplicity of the J16 interface.
In all of this, I am not trying to pick a winner. The issue is since we have both capabilities available in the applications, what should we choose for HL? Do we pick one or do both to maintain compatibility and flexibility. Compatibility and flexibility is helpful here for those that want a Hermes solution for far less than the cost of a ANAN-10/100, or flex or any other well architected SDR implementation. If we are just here for ourselves, we may get away with just one solution. What shall we do?
At least that is my read....
Tell me what you think. Here are some docs...
John - AC9HY
J16 seems to be
My observation is that Hermes implemented multiple external control protocols to appease multiple constituencies over time. Alex precedes J16 as I read it and is a well thought out, all encompassing multiplexing protocol, originally implemented prior to Hermes. It uses SPI and 2 strobes to latch (at the filters) state for both RX and TX needs, using 4 shift registers and buffers. State is maintained and as registers are written, prior data settings are preserved. They use it for RX and TX filter control, attenuation, preamp, XVTR, PTT and antenna switching. I have found an implementation that takes the protocol and creates a interface to allow the use of external LPFs (external meaning non-hpsdr alex hardware) with Hermes. I like theAlex protocol and implemented it for the 160M-10M PA ( Graeme - we are calling it Megaband hihi).
J16 is the connector on Hermes, that provides a cornucopia of function to external components. Part of which is a set of 7 open collector outputs, plus PTT, to control LPFs/BPFs. State is maintained in the application, not the FPGA (I think), and most of the hardware/firmware is a pass-thru. The manipulation of those bits of data is defined in a config screen in the radio application. You can use one bit per filter, or BCD or anything else that makes sense to the sender and the receiver. When transmitting, it sends the TX 7 bits, when receiving, it sends the RX 7 bits. It is pragmatic and to the point. Gives you what you need and none of the fluff. This would make the Megaband card itself simpler and lower parts count. it would not be as extendable.
J16 is described in the Hermes user doc. The other docs are self explanatory. Alex alternate is good in that it shows the logic required to implement the 16 bits of latched state. Sid's docs show the simplicity of the J16 interface.
In all of this, I am not trying to pick a winner. The issue is since we have both capabilities available in the applications, what should we choose for HL? Do we pick one or do both to maintain compatibility and flexibility. Compatibility and flexibility is helpful here for those that want a Hermes solution for far less than the cost of a ANAN-10/100, or flex or any other well architected SDR implementation. If we are just here for ourselves, we may get away with just one solution. What shall we do?
At least that is my read....
Tell me what you think. Here are some docs...
John - AC9HY
J16 seems to be
Zl2APV
Jan 20, 2015, 11:17:54 PM1/20/15
to herme...@googlegroups.com, boyc...@gmail.com
Thanks Guys for the info. I guess it doesn't matter too much what we do to interconnect the FPGA to the filter boards etc. but the output needs to be a J16 type interface. So it really comes down to how hard it is to get lots of output and input pins from the Hermes-Lite (physically) e.g. with a direct driven J16 we need 7 Rx and 7 Tx I/O pins plus a Tx/Rx pin as a minimum, then we need to decide if we want an analogue feed from an swr bridge as most SDR's will use this info and any other input/outputs we may decide on. It comes down to Steve a fair bit here as he is going to have to program this into the FPGA and he is going to want us to develop an interface board for whatever he does. I see the options as follows ...
1. Dedicated I/O lines
Pros ... dead simple to implement, probably already in the Hermes code right now and only needs the lines buffered.
Cons ... Gobbles up heaps of I/O lines and will pose difficulties getting from Hermes-Lite board.
2. I/O via I2C bus
Pros ... Uses the minimum number of I/O lines and may be already in Hermes. Easy to signal to remote linear, antenna rotator etc.
Cons ... Needs an interface board (maybe a PIC or Arduino) for decoding. Decoded lines will need buffers and slight possibility of Rf noise.
2. I/O via SPI bus
Pros ... As for Pros of 2
Cons ... Each device being controlled needs and extra I/O pin for control so I/O's used is proportional to number of devices.
The interface board (Needed for all options but of varying complexity) should have the 7 Rx and the 7 Tx control lines via J16. A Rx/Tx line which needs to be spec'd for Rx at ground or should it be Tx at ground also a delayed PA bias signal to avoid hot switching as the base point. We need input from interested parties on what other controls we may wish to implement in future so we can draw up a spec. bearing in mind what Hermes already does and not to press for frills until the base work is going.
Steve you need to join this working group as you are going to be stuck with the coding. We can get any info you need on what Hermes does etc. and do any other donkey work to lighten your load. I don't have my boards or the socket yet so still can't fully participate but I can still read hi.
73 Graeme
1. Dedicated I/O lines
Pros ... dead simple to implement, probably already in the Hermes code right now and only needs the lines buffered.
Cons ... Gobbles up heaps of I/O lines and will pose difficulties getting from Hermes-Lite board.
2. I/O via I2C bus
Pros ... Uses the minimum number of I/O lines and may be already in Hermes. Easy to signal to remote linear, antenna rotator etc.
Cons ... Needs an interface board (maybe a PIC or Arduino) for decoding. Decoded lines will need buffers and slight possibility of Rf noise.
2. I/O via SPI bus
Pros ... As for Pros of 2
Cons ... Each device being controlled needs and extra I/O pin for control so I/O's used is proportional to number of devices.
The interface board (Needed for all options but of varying complexity) should have the 7 Rx and the 7 Tx control lines via J16. A Rx/Tx line which needs to be spec'd for Rx at ground or should it be Tx at ground also a delayed PA bias signal to avoid hot switching as the base point. We need input from interested parties on what other controls we may wish to implement in future so we can draw up a spec. bearing in mind what Hermes already does and not to press for frills until the base work is going.
Steve you need to join this working group as you are going to be stuck with the coding. We can get any info you need on what Hermes does etc. and do any other donkey work to lighten your load. I don't have my boards or the socket yet so still can't fully participate but I can still read hi.
73 Graeme
Steve Haynal
Jan 21, 2015, 2:20:02 AM1/21/15
to herme...@googlegroups.com, boyc...@gmail.com
Hi John, Sid and Graeme,
Thanks for the discussion regarding the Hermes' J16 connector. I like that the PowerSDR and now QtRadio have a way to simply specify what signals on this connector should be for different bands and for RX/TX. I added these 6 user outputs to the latest firmware (20150120) and updated all the schematics and pdfs. I called the signals userout0-userout6 as they are more akin to the usrout signals driving U22 in the Hermes Schematic. Note that U22 inverts these signals and provides much more drive. A designer of a frontend card can decide whether to use these signals directly from the FPGA or provide buffering. See http://www.altera.com/literature/an/an447.pdf for more details on the 3.3 LVCMOS standard used by the FPGA.
73,
Steve
KF7O
John Williams
Jan 21, 2015, 7:19:06 AM1/21/15
to herme...@googlegroups.com
Perfect! Working on a change to the Frontend board to add a UNL2003A
for open collector buffering as is done in the Hermes design. Since
we have a proto area on the current board, will be able to add a DIP
version of the chip to allow for progress prior to next revision. I
will update my fork and make necessary changes to your frontend
board design, if that is OK with you?
Super progress guys!
John - AC9HY
Super progress guys!
John - AC9HY
Sid Boyce
Jan 21, 2015, 11:37:27 AM1/21/15
to herme...@googlegroups.com
Hi John,
I am agnostic about the implementation as the PA/Filter is designed to work with Hermes-Lite rather than to accommodate multiple schemes.
As I would be looking towards the Megaboard, however it's implemented suits me.
I am agnostic about the implementation as the PA/Filter is designed to work with Hermes-Lite rather than to accommodate multiple schemes.
As I would be looking towards the Megaboard, however it's implemented suits me.
73 ... Sid.
On 20/01/15 16:56, John Williams wrote:
--
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.
For more options, visit https://groups.google.com/d/optout.
joe
Jan 21, 2015, 11:45:24 AM1/21/15
to herme...@googlegroups.com, boyc...@gmail.com
Hi John,
Can you recommend any other IC's to buffer the FPGA? Anything that doesn't need pull up resistors on input?
I would just like to buffer without extra parts if possible ground or 5v output is OK I'm trying to add the buffer to the existing front end board.
Thanks Joe
Steve Haynal
Jan 22, 2015, 1:01:06 AM1/22/15
to herme...@googlegroups.com, boyc...@gmail.com
Any CMOS buffer should work
The direct FPGA outputs are pretty robust as long as you don't really abuse them.
73,
Steve
KF7O
Zl2APV
Jan 22, 2015, 4:51:23 AM1/22/15
to herme...@googlegroups.com, boyc...@gmail.com
A useful buffer is the 74LVC4245 which is also a 3.3 to 5 volt level translator. I use this in my HiQSDR and it works fine.
73 Graeme ZL2APV
73 Graeme ZL2APV
Tim O'Rourke
Jan 26, 2015, 11:20:12 AM1/26/15
to herme...@googlegroups.com
One thing to consider is where this connector originated from, Penelope.
If you look at Penny documentation you will see the open collector outputs AND analog Fwr/Rev inputs to ADC chip.
These same signals also arrive from Alex connector actually go back to Mercury A2D chip if memory serves (questionable).
If you want one connector IE DB25 style that truly has had support from beginning developers check out this DB25 on Penelope.
For example Hercules Amp from Gerd Louch (see HPSDR Wiki) used this for control of this amp, including Fwr/Rev measurements.
Hermes missed the boat when they implemented J16!
Tim W4YN
Joe
Feb 12, 2015, 10:45:50 AM2/12/15
to herme...@googlegroups.com
I have some confusion about the filter control leads on CN2. I'm currently using them active high along with a
1K pull down resistor to ground driving a ULN 2003.Everything works okay however I'm concerned that I might be stressing the FPGA.
by supplying to much current. What are the actual conditions on these leads open-3.3v or ground -3.3v?
are the pull down resistors actually needed Since the 2003 only requires a couple of MA when the input is 3.3v I assume
this is okay.
Thanks Joe wa9cgz
Steve Haynal
Feb 13, 2015, 10:43:32 PM2/13/15
to herme...@googlegroups.com
Hi Joe,
I think you are okay. I plan to up the current handling of the external pins in a later revision. They are set to 2 mA now which really means they won't switch as fast as you like if you use more current, but shouldn't be an issue for the type of slow control CN2 is used for. The IOs are pretty rugged. You can find more details here.
73,
Steve
KF7O
Reply all
Reply to author
Forward
0 new messages