A post from Steve at Flex
- 303 Likes
Once we realized it was possible to build a direct sampling radio, all the "what if..." conversations started. What could we do if we did this? What would someone do with that? Would it be better if we did this or that? At the time, PowerSDR was the de facto standard in SDR, but we were keenly aware of the limitations of the architecture. Namely that it would not work well in the IoT (Internet of Things) age, remote would be a kludge, the more data we wanted to process the more powerful computer you would have to buy, etc. It's just not scalable. At the time, the HPSDR team had built a working direct sampling receiver and we looked over their architecture and considered it. It also had the critical flaw of having to have a fat communications pipe to the computer. We decided putting the processor in the radio was the way to go.
We contacted Intel, Freescale, Texas Instruments, Xilinx and Altera and had meetings with each to discuss what technologies we could use to build the compute engine in the radio. We briefly discussed doing everything in an FPGA, but this was quickly ruled out because it takes roughly 10x to build the same thing in an FPGA as you can build in a processor. Our Avnet/Xilinx FAE at the time put it very matter-of-factly when she said something like: "FPGAs are hard. You wouldn't use them if you had any other way of doing it." But to do direct sampling, an FPGA was required. At this point we knew that we were going to be marrying an FPGA and a processor. All the while that we are making these decisions about the hardware, I'm thinking about how the software will work and building the architecture for that in my head.
FPGAs can have what are called "soft processors" which are processors that are actually built in the fabric of the FPGA. We have used these before and they can be handy, but there is a key problem: all of them are limited to about 100-150MHz of clock speed. We knew that this wouldn't cut it. Several of the FPGAs have what are called "hard processors" which are processors that are part of the silicon and they run at native speeds, in the 750-1500MHz range. Xilinx previously had used PowerPC, but now was promoting a new family called Zynq which included an ARM processor. The world has largely abandoned PowerPC and MIPS and settled on ARM for embedded licensed processors. We liked the ARM architecture and the toolset and toolchain were rich -- we were sure that ARM would be around for a while. But Zynq was expensive and and brand new.
We talked with Intel who had a line of embedded processors and we liked those OK, but there seemed to be a lot of interface work required with them. We moved to talking with Freescale and TI because each had DSP processors which we felt would give us a lot more power since we were going to be doing DSP. TI was a full generation ahead of Freescale at the time so we got serious about TI. TI had better raw compute power and we really liked where they were going so we picked TI. We also had a good relationship with TI and felt like that would help us. All the while that Gerald and I were visiting with these companies, we would walk out of the meetings and talk about what we could do for ham radio with each solution.
We ended up picking Xilinx and TI for the computing parts. At this point, I had a pretty good idea what the software architecture was going to look like and so Eric and I started talking about the software architecture in detail. Our codename for the radio was MICROBURST and SmartSDR's codename was SMOOTHLAKE. Eventually, SMOOTHLAKE got the name SmartSDR and I think it was from Klaus, DK7XL, our EU representative.
The path we picked was filled with peril and we received advice that we could easily kill the company with the decision we had made. We knew that if we could do this, we would advance the technology in ham radio in one huge leap. Gerald asked the team if we were committed to making this radio happen. This is one of those moments where someone looks you in the eye and you know that this is a real commitment -- if we failed, there would be grave financial consequences for us and our employees. Everyone made a commitment and we got to work.
Gerald started working on the hardware design and picked other key parts including the DAC, the Codec, power supplies, etc. As I recall, Eric and I started coding before we had hardware. Gerald did most of the PCB design and layout and I did some of the mind-numbing layout work on the ADC, DAC and DDR3 memory. At some point we got a working PCB and we started the effort to bring up the processor. Hardest. Thing. Ever. I'll spare you the details, but Eric and I spent about 3-4 months bringing up the processor. I am so much smarter now than I was then.
At this point, Eric and I sequestered ourselves and wrote the core foundations of SmartSDR. We spent hours at my house in the lab writing software and we would periodically call in and let everyone know what we were able to achieve. Gerald was off designing the PA while we worked software magic. Bob McGwier, N4HY, visited a couple of times for about a week at a time and helped us write DSP software. We would literally get up at dawn, eat breakfast and then go into the lab and work, emerging only for food. We had only one or two working prototypes at the time. At one point we decided to pull a joke on Gerald. I rigged a couple of 1/4W resistors to a 12V supply where they would sink about 5W and we taped it to the bench. We called Gerald on FaceTime and Bob was supposed to tell Gerald what we had working. At a key point, I flipped the switch and smoke came billowing out from under the prototype and Bob feigned despair that the prototype was destroyed to tease Gerald. As it turns out, we had a communications issue and all that didn't make it to Gerald so he was spared the grief, but we all got a laugh out of it. My bench still has a small black scar from the resistors ;-). I don't know how many hours a week we were working, but it was a lot. We would get to the point in the evening where the code we were writing didn't make sense and we would go to bed and get up the next day and do it over again.
From the beginning we knew many of the things the radio would be capable of based on the hardware and we did things in the hardware to make sure we could do as many things in the future as we could dream up. To this day, we have a long list of fantastic things that we can do in the radio and the main thing standing in the way is writing the code. We continue to add new ideas to that list and work on all the things on the list. As the FLEX-6000 has continued to sell well, we continue to hire more engineers to execute that list faster and faster. Now the ideas come from everywhere -- customers, advisers, employees, etc. We work on key priorities and the best ideas based on an internal plan (much of which is shared with you in the roadmap).
So there's essentially in the design process there is communications between the hardware designer knowing the available parts and the software architecture designer on what's possible. The hardware guy might say "if I add this capability, could you use it?" or the software guy might say "is there any way you could give me thins kind of data?" You work together to figure out what gets you the most value for the buck and the engineering investment and you go with that.
Designing and building the FLEX-6000 and SmartSDR with the team at FlexRadio has, without a doubt, been the most rewarding experience in my career. I've never worked with a better team of people. With the SmartSDR foundation, our engineers can visit with a customer at a hamfest, hear a great idea, say "I can do that" and then return home and make it a reality. As an engineer it's extremely satisfying to be able to envision what a customer wants and be able to make that a reality. The FLEX-6000 hardware platform is the most programmable platform we've ever had and we can do just about anything on it -- which is why we designed it the way we did.
Sorry for the novel! I hope it gives you some insight into how we do this at FlexRadio. It's probably different other places, but there are probably similarities.