Call Search

New to Ham Radio?
My Profile

Friends Remembered
Survey Question

DX Cluster Spots

Ham Exams
Ham Links
List Archives
News Articles
Product Reviews
QSL Managers

Site Info
eHam Help (FAQ)
Support the site
The eHam Team
Advertising Info
Vision Statement

  Home Help Search  
  Show Posts
106  eHam Forums / Software Defined Radio / RE: There are Visalia Videos of the FlexRadio Flex-6700 demo station on: April 25, 2013, 03:45:59 PM
I'm very eager for the Flex-6700 "ears" as Howard VE3GFW reported:

In spite of the limitations of the beta test software, the [Flex-6700] receiver performance was astounding.

It appeared that the radio was hearing down to -142dBm (or about S0 – 15db or almost 2 ½ S Units below S0)

BUT what was more astounding was that they introduced DSP gain into the system so that it could hear down to -149 dBm or about the phase noise levels. I am not sure how to measure down to those levels as the thermal noise in my test equipment is higher than that. (The figures are un-calibrated- we will see what Sherwood says)
Adjacent Channel rejection appeared be out of the world….you could totally block an S9+40db signal 100Hz away…..

Like Howard VE3GFW says the Sherwood numbers promise to be impressive.

S9= -73dBm so 40 over is -33dBm.. Against -142 dBm this is about 110dB of instantaneous dynamic range, or about 18-19 bits in the ADC.  So it's impressive that they held that level of performance through the analog processing chain, but not exactly world beater in a DSP radio (it would be very challenging using LC or crystal filters).
  There are a lot of other aspects of performance that will be important.

I'd be more interested in seeing what their output spectrum looks like.  How well do they suppress the DDS and the image? Over frequency, time, and temperature.  How well can they keep that adjacent channel performance over time, frequency, temp, etc. How often do you need to recalibrate to hold that performance.   Stuff like that.
107  eHam Forums / Software Defined Radio / RE: There are Visalia Videos of the FlexRadio Flex-6700 demo station on: April 22, 2013, 05:44:14 PM
Software is hard, and worse is the next best thing to impossible to estimate reliably, real time software is an order of magnitude harder, realtime on a multitasking general purpose machine is harder again (And is just plain nasty to debug).
You bet..
PCs provide a lot of cheap compute power, but low and deterministic latency is not their strong point.

Never underestimate the pain of going from a prototype to a product, especially when MS Windows is in any way involved.
Flex started as a sort of hacker platform. Gerald provided the basic VB core to get it working.  Later, they picked up dttsp (in C) as the engine and VC# for the UI stuff.  The idea was that dttsp would be a nice reliable open source signal processing core, and that the bazaar would provide enhancements both for the dsp and UI. 
It worked fine for what it was.   But the user base grew (very quickly) and those users were not SDR hackers looking to scratch an itch.  They were hams wanting an inexpensive high performance radio to compete with the multikilobuck radios. I suppose you could say it was the transition from a prototype (the hacker platform) to a product (orders of magnitude more users than coders).

That said, Windows (while a pain in some ways) didn't make it horribly harder. Had they run under Linux from day 1, they wouldn't have had the transition: it would still be a hacker platform.  More importantly, Gerald would never have built the first one, because he worked in VB, and that's a Windows only product. I think it was a great thing he did.  He didn't get wrapped around the axle about needing a special DSP processor, or trying to link to some fancy DSP library, or even fooling with gnuradio.  To say nothing of the absolute PAIN it was trying to get audio devices to work under Linux was back in 2003.   He figured, hey, my PC is fast enough to do simple DSP in VB, why not build a radio. And he did.

ANd that motivated a horde of folks to get with the program and make serious efforts in PC based SDRs.  Phil Covington had an idea to build a SDR, and got convinced that it would be productive to build high performance audio interfaces to improve the performance of the SDR1k, and that got a lot of people involved in other SDRs.  There were a lot of bumps in the road there, too.  The SDR1K existing, or more properly, the existence of PowerSDR which was flexible enough to support other hardware prompted the development of the SoftRock, a very cheap SDR using a crystal instead of the DDS. 


What could be interesting is investigating the possibility of using a small dedicated compute board as a baseband processor for the anan/hermes radios, possibly itself with FPGA support or using CUDA or something, this would sit as a shim between the userland devices and create the the very high bandwidth I/Q data stream for the radios as well as doing the FFTs and suchlike, allowing the controls to run in a rather less time constrained environment.

I am thinking something like a TMS320C6xxx or SHARK, a Gb network port for the radios and a second network interface for the user network. The DSPs can handle the baseband processing without breaking a sweat, and can do it with negligible latency as they can work sample by sample in interrupt context rather then having to do blockwise processing like a PC does. As memory serves Hermes at least lets you select the amount of decimation in the CIC chain so it may well be practical to run at baseband bandwidths limited only by the network bandwidth to the radio.
Such things have been around for a while, and never got traction.  DSP-10 for instance.  The problem, fundamentally, is that there are relatively few people actually interested and skilled enough to fool with the DSP side of an SDR. So the sales volume of your radio will be small, unless there is "off the shelf" software that makes it work. Today, YOU could go out and build yourself an SDR with your processor of choice (use an eval board, like Bob Larkin did for the DSP-10).  But then you're constrained to work with THAT processor, and whatever you choose, it won't be as common as an x86 based PC. Pretty soon, that processor will be obsolete, you'll be running the dev tools in emulation, etc.   

For a more modern, and fairly well supported, device, take a look at Matt Ettus's USRP (also available from National Instruments). It's a nice hacker platform, has an FPGA, hooks up to gnu-radio.  Hundreds of them have been used by undergrads and grad students for senior projects, thesis projects, and PhD dissertations.  They're also used a lot in industry, and as "cell site emulators" for a variety of purposes, some good, some evil. 

This is essentially where the 6000 series is trying to go, but I want something hackable, including having the VHDL/Verilog be hackable, however good the supplied API may be, sooner or later you will hit something it will not let you do, and that sort of defeats the point of an SDR for me.
Yes.. the USRP is what you want.  The F6.xK or the F5K or the F3, etc. are what the average ham SDR buyer wants: a turnkey box with easily installed software upgrades provided "by others".  I'm sure others will spring up in that market.  There are SUBSTANTIAL challenges: software development costs are but one (since "open source" did not provide a free (as in beer) option); there's also a host of regulatory issues.  It's one thing to sell a box o'parts to a hacker in small quantities; the FCC is going to let you do whatever you do, just like if you cobbled together a rig using that surplus PTO and those 6146 tubes you got from an estate sale, with some sockets you made by drilling holes in some beer coasters.

However, start selling a "box" with a "user manual" and such, and they're going to ask questions like "how do you block reception of cellular frequencies?" and "how do you prevent out of band emissions?" and "could you demonstrate that your spurious signals meet good engineering practice"

That's the "prototype to product" transition you mentioned, in real life..
108  eHam Forums / Software Defined Radio / RE: Spurious signals in SDR on: April 14, 2013, 11:31:19 AM
It sounds however like the problem flex had was probably something mundane and hardware related rather then being a problem in the vhdl/verilog.

No verilog or vhdl in a Flex. It's all C running on the PC.

The problem with low bands on Flex comes from the basic architecture.  It uses a form of vector modulator on a DDS produced carrier.  The I/Q signal is setup as a few kHz offset from zero (to get around problems with DC response of sound cards in the first flex).  If the I/Q balance isn't perfect, you get an image below the carrier, as well as some carrier feedthrough.

The way the (analog) modulator works uses a I/Q version of the carrier generated by a DDS that puts out quadrature outputs, but there are discrete component 7th order filters on the output of the DDS. They match pretty well, but not perfectly.  Ditto with the audio band I/Q from the sound card.

All potentially calibrate-out-able, but the calibration changes with temperature, carrier frequency, and isn't constant across the I/Q passband.   It's easy to get 20-30 dB carrier and image suppression with a single point cal (ignoring the above), and that works for typical HF usage, where the person receiving is seeing the signal at 20 dB above the noise floor (they don't see the low level carrier and image). When folks doing top band CW started running high power amps, all of a sudden, that 30dB image is pretty noticeable.

The original SDR-1K with the original sound card interface is doomed in this situation, because it has no DC response to take out the offset term in the I/Q.  I think the F5K has DC coupled DACs to the modulator, but I haven't seen a schematic, so I don't know for sure.

There were several schemes for a loopback "self cal" in the F5k design, but I'm not sure they ever worked well, or were really thought through fully. Essentially, you need to have a good receiver with good instantaneous dynamic range and good image control with which you can look at the transmitter output and adjust the image and carrier down to zero. You can theoretically do this with the receiver that's already in the radio, but then you have to calibrate the receiver first.  And you really need to be able to set the center frequency of the receiver to something different than the center frequency of the transmitter (so you can use the unmodulated Tx as a tone source to calibrate the receiver).  The SDR1K can't do this (it's a half duplex radio).  The published F5K block diagram is unclear whether a single receiver F5K can have different frequencies for Tx and Rx chains (the dual receiver certainly can), and I'm not motivated enough to go look at the controller source code to see if it can.
109  eHam Forums / Clubs / RE: Clubs with physical facilities on: April 13, 2013, 05:28:32 PM




110  eHam Forums / Antenna Restrictions / RE: FCC seeks to reassess RF exposure limits on: April 08, 2013, 09:12:08 PM
This is fairly normal and not particularly unusual in the regulatory world. Any time there's a special case (e.g. an exemption for hams) one would ask whether you can do away with the special case (regulatory simplification and all).

Doing a decent RF safety evaluation isn't all that hard (it's a lot easier than learning CW). There's plenty of simple analysis that a ham can do that would assess the exposure, so the need for a "no analysis safe harbor" is sort of small.

There's also the "multiple transmitter" problem. The regulations require that if there is more than one transmitter, you need to do the analysis, not take the exemption.  And that's not just ham transmitters, the cell phone and the WiFi and the BT and everything else count too.  There's a "less than 5 percent" exception, but I would venture that the fields from the cellphone are comparable to, if not greater than, the typical fields from a HF or VHF antenna.

There's also this problem:"exempt transmitting antennas that are unusually close to people could potentially lead to non-compliant exposure levels"  

Pictures in QST of people running mobile VHF rigs or HF compact loops on picnic tables running 100W don't help things.
111  eHam Forums / Software Defined Radio / RE: Ham Radio Deluxe on: April 07, 2013, 11:17:27 AM
check your longitude and make sure it's the right sign or that you didn't drop a zero somewhere.
112  eHam Forums / Software Defined Radio / RE: Spurious signals in SDR on: April 07, 2013, 11:16:35 AM

An interesting question.
There's not a lot of good books on DSP/etc tailored to SDRs in a general sense. There are textbooks like those by Proakis or Oppenheim & Schaefer (and used versions should be available less expensively than new), but they tend not to talk as much about non-ideal behavior (e.g. what does it look like when you clip into the ADC).  Partly this is because classical signal processing makes the assumption of linear behavior (or, at least, idealized non-linear: multipliers are perfect). 

When it gets to non-ideal behavior, you're getting into specific implementations.  Journal articles on various aspects of this are where the information is: for instance, spurs in DDS output is the subject of a variety of articles, and even a couple specialized books. 

I don't know that there's a SDR equivalent of, say, Rhode's "Communications Receivers" which is a great overall review of analog receiver design. (with some DSP, too).  There are a fair number of newer books out on SDR, but they tend to focus on data radios, given the fact that commercial radios are virtually all carrying data, not analog signals, and so the analysis tends to be in terms of things like effect on bit error rate (BER), or perhaps on error vector magnitude(EVM).

There are also an enormous number of useful applications notes out there from TI and Analog Devices on various pieces of the signal processing chain: ADCs and DACs are where the rubber hits the road in terms of performance, and there's lots of ap notes on them and their various non-idealness.

But.. if you're looking for a discussion of "typical spurious signals" you might find it a bit hard to find.  ARRL handbook has some.   In general, you're going to see the following kinds of spurious sources (over and above the usual ones from the analog circuitry):

1) clock leakage - intermods and sampling artifacts with the clock frequency and multiples thereof.  I have a receiver which shows an interesting spur that turns out to result from the 66 MHz CPU processor clock leaking into the 49 MHz sampling clock (or the power supply), so I see intermod products at combinations of 66 and 49 and multiples thereof, some of which appear in band.
2) aliases - there's no such thing as an ideal anti-aliasing filter, so you wind up with what would normally be out of band spurs showing up at in band frequencies as the result of aliasing.
3) DDS spurs  from phase truncation or from finite DAC resolution - there's a whole literature on this.
4) Spurs from overloading the ADC.  This can result in what are essentially intermods with the sample clock rate or multiples, that alias back into the sample bandwidth.
5) I/Q modulator leakage. Either the carrier getting through, or the image showing up.  40 dB is doing quite well for I/Q modulators, but 40dB down can be pretty big, if the desired signal is large, and it's often in an unexpected place, compared to what people expect from conventional radios.
113  eHam Forums / Software Defined Radio / RE: Flex-5000A CW Impressions on: April 05, 2013, 06:34:40 PM
Anyone know what architecture Flex uses when sending CW? I bet the key input gets sent up the Firewire port to the PC to be processed before being sent back down the link to the radio hardware as an RF waveform
Midi messages

They would have been better off putting a $0.50 Pic MCU in the box and using that to directly key the transmitter, even if the radio's internal firmware has to generate the RF waveform directly. A simple on-off keyed CW signal can't be that hard to generate to require a fast PC's processing power.

That's not how it generates CW (nor how any SDR would generate it): you're thinking in terms of traditional analog radios where you do something like turn the final amplifier on and off (or perhaps one of the stages, and then feed it to a linear amp).

In an SDR, you just generate the sine wave (envelope shaped to reduce key clicks) that you want transmitted.  Think in terms of something like hooking the output of a code practice oscillator to the input of a SSB rig.

The challenge with the PowerSDR software architecture is that the latency through the chain can vary somewhat.  The transmitted signal is ok, but has a variable delay from the input to the chain, so if you listen to your own transmitted signal, you'll be confused.  The recipient on the other end of the path doesn't care.. he or she hears normal CW.  Another term for this is "pipeline delay" and such a delay exists in ALL radios (even analog ones).  The delay through a filter with a given bandwidth is roughly 1/Bandwidth * number of sections. So if you have a 50 Hz wide filter, you're going to have a 20 ms delay (at least).  In the Power SDR, the delay is more about the block size in the DSP. SHort blocks mean shorter absolute delay, but the filter performance isn't as good.  You want a 1 Hz transition in a brick wall filter? that's a 1 second delay.

The other challenge faced by the PowerSDR architecture is T/R switching.  In the early versions (fixed at least 4-5 years ago, I think), you had to wait for the audio buffer to finish before it could be "turned around" to the other direction. That's probably the "missing dit" thing.  When they fixed the buffering so that it ran full duplex (at a cost of doubling the CPU burden), that particular problem went away..

The other tricky aspect to the PowerSDR architecture is that it potentially has multiple blocks of data stacked up through the chain in both directions.  You really, really don't want to have the Transmit DACs "run dry" (because you'll be emitting a big CW carrier at the DDS center frequency with fixed values of I and Q until the next set of samples arrives), so you want to have a few blocks queued up, in case the PC decides to go do something else for a short time.  If you're watching a DVD and you hesitate a frame or two, you might not notice.  But if the last set of samples happened to be full scale I & Q on a Flex, then you're transmitting full power carrier until the next samples arrive.  A good design (which they may have done in the firmware between 1394/Firewire and DACs) would have some default "zero" value (chosen to minimize feedthrough of the DDS) to clock out if samples don't arrive over the firewire in time. 

In any case, the need to have extra blocks in the pipeline so the FIFO doesn't run dry also leads to longer delays.
114  eHam Forums / Antennas and Towers and more / RE: above groung vertical with 1 radial on: April 05, 2013, 05:33:08 PM
Since it's a SteppIR, the "matching" issue isn't a big one.. you just adjust to wherever you get a decent match.

As others pointed out, with one radial, it's basically a V dipole on its side. It won't be particularly directional.  Depending on the height above ground it may or may not be inefficient.

However, it will work.
115  eHam Forums / Satellites / RE: Asked Mirage/MFJ for D310G on: March 29, 2013, 09:25:12 PM
Why is low gain antenna and more RF power "poor practice"?  Either you have the EIRP to close the link or you don't.  One might have a personal preference for "efficiency" or have a regulatory limit (the 50W limit on 70cm in many areas of the US) which forces you to a high gain antenna and low Tx power.  But those are more "preference" than "good practice". 

It's all a matter of system engineering.  You can spend money and complexity on a gain antenna and pointing, or you can spend it on RF power amps.  If you wanted to do satellite mobile, you'd probably go with the low gain antenna and the RF power: the complexity of pointing on a moving platform is substantial.

(no discussion here about downlink/Rx side performance.. There's not as much room for "buying performance" when it comes to LNAs. 2 dB difference from good to not so good is about the range.)
116  eHam Forums / Satellites / RE: Feasibility of making 2 way contacts to a space ship on trajectory to Mars? on: March 27, 2013, 09:37:47 PM
The modulation mode needs to be picked smartly as well as required ERP-Power/band. Here is where digital FM using Manchester (self correcting) type code is needed to minimize solar interference to obtain the best clarity in the smallest bandwidth yielding the most power out.
Why FM at all?  Go with something simple and proven, like BPSK. If I were building it, I would start with BPSK using a fairly fast PN spreading code (say, 1-10 Mchip/second), and then modulate my low rate data on top of that.  There's a lot of off the shelf hardware/software to acquire the PN codes (e.g. GPS receivers do it), and that makes it a lot easier on frequency control (which is challenging with Doppler and all).  The Space Network (TDRS) uses a similar scheme with spreading codes at about 3 Mchip/second.

Mars HAM comm's will take some serious ground equipment to allow the space craft to keep the size/weight down/reasonable to add HAM OPs!
There's a project going on now at JPL to build a deep space cube sat (INSPIRE). The radio design is adaptable to ham bands, and fits in <1U, and should work with ground stations in the <10 meter class.  It's using standard CCSDS modulation schemes and is DSN compatible.  Since the core of the radio is a FPGA, implementing some other modulation scheme is a matter of writing the software.

There's an off the shelf implementation for the Space Network modulations, including the PN spread modes, that fits in a 3 million gate Virtex II available from NASA Glenn Research Center. (if you're a US Person.. export control is always an issue, even for hams).
Here is where I suggest parroting established NASA Comm methods and pick near HAM bands for the distance and power required for reliable comm's.
Not necessarily copy what NASA does.  Remember that legacy support is important to NASA, and a lot of what NASA does is based on decisions made on the basis of hardware that was available a long time ago. We just stay with it because it works, not necessarily because it is what you would find best if you were starting today.
Next question is of NASA big RX dishes - can/will add a HAM RX antenna interfaced to the internet so all on Earth could listen into Mars HAMComm's (and as an emergency comm alternate backup). This would cut half our personal HAM station costs if we can tap into NASA. 
117  eHam Forums / Satellites / RE: Feasibility of making 2 way contacts to a space ship on trajectory to Mars? on: March 16, 2013, 08:51:24 AM
Brilliant question:

..... "Roger your plan to go EVA and replace Alpha-Echo three-five unit prior to faliure."

I think the store forwarding of messages will be the way to go - well done Mr Clarke.

How much ERP will be needed to give them enough bandwidth to run Netflix to pass the time  Cry

Funny you should ask... This is the kind of thing that folks at JPL figure out every day.  We send several Mbps  (which would be enough for Netflix) back from Mars from MRO.. about 100W into a 3 meter antenna at 8.45 GHz.  This gives about 66 dBW EIRP (4 Megawatts). some measurements for Ka-band (32 GHz).. about 70 dBW EIRP, using a smaller amplifier

The multimegabit rate is into a 34m antenna on the ground, I believe, although it might be the 70m  (1:4 difference rates between the two).

Going the other way, from ground to earth, is easier. The noise figure on the spacecraft isn't as good as the cryogenic receiver on the ground, but it's easy to get 10s of kW transmitter power on the ground.   So, at least at Mars, streaming Netflix, Hulu, or Youtube to the astronauts is not a problem. (except perhaps for licensing and region restrictions<grin>)

Now, I will grant you that a 34 meter antenna is a big bigger than the average ham might have in their backyard, but there are people who have big antennas (Jamesburg dish, Bochum, etc.)  and there are a LOT of 6-20 meter dishes around which could easily be pressed into service for, say, kilobits/second.
118  eHam Forums / Satellites / RE: Feasibility of making 2 way contacts to a space ship on trajectory to Mars? on: March 16, 2013, 08:38:40 AM
True, just at the moon there is a 4-5 second delay one way
actually, more like 1 second. Moon is about 300,000 km away and speed of light is about 300,000 km/sec.

Quote Mars, its a 12 minute delay one way...

Rough numbers.. Mars is 1.5AU from sun, we're 1 AU. If you recall, it takes a bit more than 8 minutes for light from the sun to get to Earth.  So when Mars is closest (0.5 AU) it takes 4 minutes, when Mars is farthest (2.5 AU) it takes 20 minutes.
.packet or a digital mode would be best...voice comm would not be very feasible...which really complicates the landing sequence.....mission control would not know if the landing was successful until after it happened....but that 7 min entry into the Martian atmosphere are know as the 7 minutes of terror...with the robots, if we lose the telemetry, its gone...on manned mission, its possible the screams of terror, etc would be heard...after it happened....still, I would chance it..the biggest problem is GETTING there..cosmic rays and other issues may make a flight to Mars highly unsafe for decades to come...the moon was a pond jump...Mars is the ocean a dingy
119  eHam Forums / Satellites / RE: Feasibility of making 2 way contacts to a space ship on trajectory to Mars? on: March 16, 2013, 08:32:42 AM
How feasible would it be to work a ham radio station on a space ship on trajectory to Mars and back?
not too hard from a technical standpoint..
The problem is that once you get very far away (the moon is 1 second away), you want to probably move towards a more "messaging" rather than "conversing" mode. 
Has anybody thought of this and what kind of station would you need in the space capsule and on earth?

I guess stations with EME capability might be able to pull this off  Smiley

Easier than EME.. EME is a two way path with 1/r^4 loss.  Of course, once you get to twice as far as the moon, you're matching EME.  While you can have W5UN's array on the ground, you don't get that on your spacecraft, so...

You want to go higher in frequency for a variety of reasons.   Today, with readily available components and such, the 10.5 GHz band is a sweet spot. Parts are still inexpensive, test gear isn't all that pricey since it's <18GHz.  A 1-2 meter antenna gives you a lot of gain at 10 GHz, and is still "pointable".

There's a fairly active amateur DSN community that regularly receives signals from spacecraft at lunar distances.

120  eHam Forums / Emergency Communications / RE: Future of Emergency Power: Small, Mobile Nuclear Power Plants (from Army) on: March 10, 2013, 06:13:55 AM
Lets say for a moment that there was a situation that was caused by generation and not distribution, or an issue that was distribution at a main feed level.  So we are talking about 100K homes.  Average home feed is 100 AMP. Services are 200 AMP but total draw is at most 100 for the sake of math here.  so 100K homes times 100 AMP is 10 Megawatt.

You left out the voltage in your power computation..

100 A * 240V = 24kW /household...   

100k households is then 2400 MW.

There is an assumption, though, that not everyone draws full power at the same time. Typical practice in my neighborhood is that a 50-100kVA transformer feeds 6-8 houses, or about 10 kW/house.  The local powerco engineer comments that we're a bit undersized. In the summer, there is definite light blink when the neighbor's AC starts up.