From la2ni at online.no Fri Aug 1 00:26:03 2014 From: la2ni at online.no (Kjell Karlsen) Date: Fri, 01 Aug 2014 09:26:03 +0200 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: Congratulations Warren! 73, Kjell, LA2NI P? Fri, 01 Aug 2014 07:05:14 +0200, skrev Bill Tracey : > ***** High Performance Software Defined Radio Discussion List ***** > > From > http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, > NR0V, of Santa Cruz, California. Pratt was cited for his research > leading to the development of PureSignal, "an adaptive baseband > pre-distortion algorithm used to improve the linearity of amplifiers and > reduce intermodulation distortion products emitted by software-defined > transmitters." > > Congratulations Warren, and thanks for your excellent contributions! > > Bill (kd5tfd) > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > -- Sendt med Operas e-postklient: http://www.opera.com/mail/ From meijer.ha at home.nl Fri Aug 1 00:56:10 2014 From: meijer.ha at home.nl (H.A. Meijer) Date: Fri, 1 Aug 2014 09:56:10 +0200 (CEST) Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: <1644767958.114768.1406879772837.open-xchange@oxbe3.tb.mail.iss.local> An HTML attachment was scrubbed... URL: From w4yn at earthlink.net Fri Aug 1 04:38:50 2014 From: w4yn at earthlink.net (Tim ORourke) Date: Fri, 1 Aug 2014 07:38:50 -0400 (GMT-04:00) Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner Message-ID: <3589696.1406893130994.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> This is way cool, tnx for all the FB effort for a fantastic solution! Tim Tim O\Rourke W4YN at ARRL.Net Low Power Amateur Radio Rocks Member of Flying Pigs,ARCI,GQRP,RSGB,ARRL Life Member R/C Pilot (sort of) NRA Life Member NRA Certified Rifle, Pistol, Black Powder Instructor, Range Officer -----Original Message----- >From: Bill Tracey >Sent: Aug 1, 2014 1:05 AM >To: HPSDR list >Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner > >***** High Performance Software Defined Radio Discussion List ***** > > From >http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > > * The 2014 ARRL Technical Innovation Award went to Warren C. >Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his >research leading to the development of PureSignal, "an adaptive >baseband pre-distortion algorithm used to improve the linearity of >amplifiers and reduce intermodulation distortion products emitted by >software-defined transmitters." > >Congratulations Warren, and thanks for your excellent contributions! > >Bill (kd5tfd) > > >_______________________________________________ >HPSDR Discussion List >To post msg: hpsdr at openhpsdr.org >Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >HPSDR web page: http://openhpsdr.org >Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From g3vbv at blueyonder.co.uk Fri Aug 1 05:02:31 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Fri, 01 Aug 2014 13:02:31 +0100 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: <53DB81D7.8000506@blueyonder.co.uk> Brilliant News! Absolutely! 73 ... Sid. On 01/08/14 06:05, Bill Tracey wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > From > http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > > * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, > NR0V, of Santa Cruz, California. Pratt was cited for his research > leading to the development of PureSignal, "an adaptive baseband > pre-distortion algorithm used to improve the linearity of amplifiers > and reduce intermodulation distortion products emitted by > software-defined transmitters." > > Congratulations Warren, and thanks for your excellent contributions! > > Bill (kd5tfd) > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > . > -- 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 From abhiarunoday at gmail.com Fri Aug 1 07:06:25 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Fri, 1 Aug 2014 19:36:25 +0530 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner Message-ID: Congratulations Warren, well deserved, Please let me also add that it is a pleasure and an honor to work with Warren, Kudos!!!! Abhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From nealk3nc at gmail.com Fri Aug 1 07:58:12 2014 From: nealk3nc at gmail.com (Neal Campbell) Date: Fri, 1 Aug 2014 10:58:12 -0400 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: References: Message-ID: He is unbelievably talented as well as an incredibly smart dude! Add generous to that list also. Congrats Warren, I could not imagine a more worthy person. 73 Neal Campbell Abroham Neal LLC On Fri, Aug 1, 2014 at 10:06 AM, Abhi A wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > Congratulations Warren, well deserved, > > Please let me also add that it is a pleasure and an honor to work with > Warren, > > Kudos!!!! > > Abhi > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scotty at tonks.com Fri Aug 1 11:23:07 2014 From: scotty at tonks.com (Scott Cowling) Date: Fri, 01 Aug 2014 11:23:07 -0700 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com > References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: <7.0.1.0.2.20140801112159.04ddfcf0@tonks.com> Congratulations, Warren! Very well deserved! 73, Scotty WA2DFI At 00:05 2014-08-01 -0500, Bill Tracey wrote: >***** High Performance Software Defined Radio Discussion List ***** > > From > http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > > * The 2014 ARRL Technical Innovation Award went to Warren C. > Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his > research leading to the development of PureSignal, "an adaptive > baseband pre-distortion algorithm used to improve the linearity of > amplifiers and reduce intermodulation distortion products emitted > by software-defined transmitters." > >Congratulations Warren, and thanks for your excellent contributions! > >Bill (kd5tfd) From ve7mdl at gmail.com Fri Aug 1 12:03:33 2014 From: ve7mdl at gmail.com (Erik Skovgaard) Date: Fri, 1 Aug 2014 12:03:33 -0700 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: Congratulations Warren and thanks for all your hard work! 73 de ve7mdl, ....Erik. Currently marine mobile as ve0mdl On Jul 31, 2014 10:05 PM, "Bill Tracey" wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > From http://www.arrl.org/news/arrl-board-lauds-unforgettable- > milestone-formalizes-lotw-policy-honors-award-recipients > * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, > NR0V, of Santa Cruz, California. Pratt was cited for his research leading > to the development of PureSignal, "an adaptive baseband pre-distortion > algorithm used to improve the linearity of amplifiers and reduce > intermodulation distortion products emitted by software-defined > transmitters." > > Congratulations Warren, and thanks for your excellent contributions! > > Bill (kd5tfd) > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/ > listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beford at myfairpoint.net Fri Aug 1 12:43:56 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Fri, 1 Aug 2014 15:43:56 -0400 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Message-ID: Well deserved recognition for a remarkable advancement of the radio art. Congratulations. Bruce/N1RX From tfox at knology.net Fri Aug 1 16:40:59 2014 From: tfox at knology.net (Terry Fox) Date: Fri, 1 Aug 2014 19:40:59 -0400 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk><53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: I just got in from a day of antenna work, and saw this. Congratulations Warren!!! Your commitment to moving PureSignal forward, along with other SDR work, is impressive indeed!! Keep it up! 73, Terry, WB4JFI -----Original Message----- From: Bill Tracey Sent: Friday, August 01, 2014 1:05 AM To: HPSDR list Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner ***** High Performance Software Defined Radio Discussion List ***** From http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his research leading to the development of PureSignal, "an adaptive baseband pre-distortion algorithm used to improve the linearity of amplifiers and reduce intermodulation distortion products emitted by software-defined transmitters." Congratulations Warren, and thanks for your excellent contributions! Bill (kd5tfd) _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From aa8k73 at gmail.com Fri Aug 1 21:24:26 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Sat, 02 Aug 2014 00:24:26 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/02 Message-ID: <53DC67FA.8060802@gmail.com> The 2/Aug TeamSpeak mp3 (67 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3509 > or < http://www.hamsdr.com/dnld.aspx > Session text follows <20:56:42> *** You are now talking in channel: "OpenHPSDR" <21:00:14> "Mike - AA8K": Congratulations Warren! <21:01:04> "Terry WB4JFI": Yes, Congratulations Warren!! Good work there! <21:01:51> "Warren - NR0V": Thanks very much. I enjoy the work and feel honored to be recognized. <21:24:05> "Mike - AA8K": Recordings: It's my way of contributing to the projects. :) <21:51:39> "Ken N9VV": Basic Configuration ? Tegra K1 SOC ? 2 Gbyte x16 memory with 64 bit width (can accommodate from 1-4 GByte total) ? 16GB 4.51 eMMC memory (footprint expandable from 16-256GByte memory) ? One empty half mini-PCIE slot with one USB and single lane PEX ? One SD/MMC connector ? One USB 2.0 port, micro AB ? One USB 3.0 port, type A ? HDMI port, type A ? TMP451 temperature monitor ? RS232 Serial port routed to UART4 ? ALC5639 Realtek Audio codec with separate MIC in and Line out jacks ? RTL8111GS Realtek GigE LAN/PHY with PEX interface ? One SATA data port ? SPI 4MByte Boot Flash device ? AMS AS3722 Power Management IC for power and sequencing ? Board ID EEPROM Signal Groups Routing to Expansion Headers ? DP / LVDS ? Touch SPI ? Camera_0 (one CSI differential data pair) & Camera_1 (four CSI differential data pairs) <21:51:46> "Ken N9VV": ? GPIO PU(6:0) general purpose IO ? UART ? HSIC ? GEN(2:1)_I2C, PWR_I2C, CAM_I2C ? Miscellaneous Power Connectors and Expansion Headers ? USB 2.0 OTG ? USB 3.0, flag configuration ? 2mm pitch Expansion headers (5x25 configuration) ? RJ45 ethernet with integrated gigabit magnetics ? HDMI type A port ? DSUB9 male serial port ? MIC-in, Headphone-out 3.5mm jacks ? JTAG 2x10 100 mil pitch THM (Through Hole Mount) ? DC power jack <21:52:37> "Rob - VE3EW": rob creswon rcrewson{AT}cinci.rr.com <21:52:53> "Rob - VE3EW": u can see i done type well <21:56:50> "Ken N9VV": Already announced Tablet last week <21:59:52> "Ken N9VV": July 23rd: < http://blogs.nvidia.com/blog/2014/07/23/why-shield-family/ > <22:01:11> "Ken N9VV": < http://www.androidheadlines.com/2014/07/nvidia-shield-tablet-now-available-299.html > <22:02:24> "Ken N9VV": Nvidia Shield Tablet for sale $299 from Amazon <22:06:51> "Ken N9VV": Lake Superior is 1,335 feet deep and 350 miles long. <22:07:05> "Ken N9VV": < http://en.wikipedia.org/wiki/Great_Lakes > <22:11:30> "Warren - NR0V": 73 ... time to go check with the XYL on the dinner plans From nu8i at cox.net Sat Aug 2 12:47:29 2014 From: nu8i at cox.net (Alfred Green) Date: Sat, 02 Aug 2014 12:47:29 -0700 Subject: [hpsdr] FM squelch Message-ID: <53DD4051.5010902@cox.net> Greetings, I'm currently using mRX PS v3.2.17 with a Hermes and homebrew transverters. I rarely operate FM, but a local station was active for the UHF contest with an FM rig on 1296, so I worked him for the point. However, the signal was pretty weak, although quite visible on the waterfall. I would have liked to have opened the squelch to assist with the copy, but setting SQL to zero didn't do the trick. I had to wait for the signal to get a good ways over the noise before the rx would open. I'm pretty sure this worked differently in an earlier release, but as I rarely do this I could be mistaken. Am I missing a setting, or is this performance to be expected? 73 Alf NU8I Phoenix AZ DM33xo From n9vv at wowway.com Sat Aug 2 13:50:40 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Sat, 02 Aug 2014 15:50:40 -0500 Subject: [hpsdr] FM squelch In-Reply-To: <53DD4051.5010902@cox.net> References: <53DD4051.5010902@cox.net> Message-ID: <53DD4F20.3020007@wowway.com> I am not sure that I can offer you a good explanation about this Alf, but you might want to use a calibrated signal source like the Elecraft XG-1 which emits a 50uv = S9 = -73db signal at 7040, and has another setting of -113db = S1 = ?uv with a switch. You can then know that your receiver is properly calibrated with any sort of input. I believe some of the more modern Elecraft calibrators allow you to select any frequency you wish. Perhaps you could substitute the calibrated signal for the IF signal coming from the transverter, and then adjust the SQUELCH on/off and level slider as needed to verify it's tripping levels in your setup. GL de Ken N9VV On 8/2/2014 2:47 PM, Alfred Green wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Greetings, > > I'm currently using mRX PS v3.2.17 with a Hermes and homebrew transverters. > > I rarely operate FM, but a local station was active for the UHF contest > with an FM rig on 1296, so I worked him for the point. > However, the signal was pretty weak, although quite visible on the > waterfall. I would have liked to have opened the squelch to assist with > the copy, but setting SQL to zero didn't do the trick. I had to wait for > the signal to get a good ways over the noise before the rx would open. > > I'm pretty sure this worked differently in an earlier release, but as I > rarely do this I could be mistaken. > > Am I missing a setting, or is this performance to be expected? > > 73 Alf NU8I > Phoenix AZ DM33xo > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From nu8i at cox.net Sat Aug 2 16:34:44 2014 From: nu8i at cox.net (Alfred Green) Date: Sat, 02 Aug 2014 16:34:44 -0700 Subject: [hpsdr] FM squelch In-Reply-To: References: <53DD4051.5010902@cox.net> Message-ID: <53DD7594.8060509@cox.net> On 8/2/2014 1:50 PM, Ken N9VV (Win-7/64) wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I am not sure that I can offer you a good explanation about this Alf, > but you might want to use a calibrated signal source like the Elecraft > XG-1 which emits a 50uv = S9 = -73db signal at 7040, and has another > setting of -113db = S1 = ?uv with a switch. > > You can then know that your receiver is properly calibrated with any > sort of input. I believe some of the more modern Elecraft calibrators > allow you to select any frequency you wish. > > Perhaps you could substitute the calibrated signal for the IF signal > coming from the transverter, and then adjust the SQUELCH on/off and > level slider as needed to verify it's tripping levels in your setup. > Tnx for the comments, Ken. The IF is well calibrated; in fact I have good sources through 10Gigs so that is not the issue. When you mentioned "adjust the SQUELCH on/off and level slider" I had an 'ah-ha' moment; clicking on the 'SQL: xx' box turns on/off the squelch. I had forgotten that was a control, but it does exactly what I needed. Maybe I should just RTFM. GL & 73, Alf NU8I From warren at wpratt.com Sat Aug 2 19:22:37 2014 From: warren at wpratt.com (Warren C. Pratt) Date: Sat, 02 Aug 2014 19:22:37 -0700 Subject: [hpsdr] FM squelch In-Reply-To: <53DD7594.8060509@cox.net> References: <53DD4051.5010902@cox.net> <53DD7594.8060509@cox.net> Message-ID: <53DD9CED.4050900@wpratt.com> Hi Alf, I got out the FM signal generator and did a quick check. All here seems to be working as expected. Setting differences could be the issue. The thing to check first is the sample rate. Because of the bandwidths involved in FM demodulation and modulation, I would not recommend using less than a 192K sample rate for FM. DSP Buffer Size might also be relevant. At 192K, I'd use 4096. In any case, if you are still having difficulty, you've found the workaround for the moment -- the squelch OFF button. Let me know if sample rate / DSP buffer size helps. 73, Warren NR0V On 8/2/2014 4:34 PM, Alfred Green wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > On 8/2/2014 1:50 PM, Ken N9VV (Win-7/64) wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> I am not sure that I can offer you a good explanation about this Alf, >> but you might want to use a calibrated signal source like the >> Elecraft XG-1 which emits a 50uv = S9 = -73db signal at 7040, and has >> another setting of -113db = S1 = ?uv with a switch. >> >> You can then know that your receiver is properly calibrated with any >> sort of input. I believe some of the more modern Elecraft calibrators >> allow you to select any frequency you wish. >> >> Perhaps you could substitute the calibrated signal for the IF signal >> coming from the transverter, and then adjust the SQUELCH on/off and >> level slider as needed to verify it's tripping levels in your setup. >> > > Tnx for the comments, Ken. > The IF is well calibrated; in fact I have good sources through 10Gigs > so that is not the issue. > When you mentioned "adjust the SQUELCH on/off and level slider" I had > an 'ah-ha' moment; clicking on the 'SQL: xx' box turns on/off the > squelch. I had forgotten that was a control, but it does exactly what > I needed. > > Maybe I should just RTFM. > > GL & 73, Alf NU8I > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From nu8i at cox.net Sun Aug 3 08:02:40 2014 From: nu8i at cox.net (Alfred Green) Date: Sun, 03 Aug 2014 08:02:40 -0700 Subject: [hpsdr] FM squelch In-Reply-To: References: <53DD4051.5010902@cox.net> <53DD7594.8060509@cox.net> Message-ID: <53DE4F10.3090503@cox.net> On 8/2/2014 7:22 PM, Warren C. Pratt wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Alf, > > I got out the FM signal generator and did a quick check. All here > seems to be working as expected. Setting differences could be the > issue. The thing to check first is the sample rate. Because of the > bandwidths involved in FM demodulation and modulation, I would not > recommend using less than a 192K sample rate for FM. DSP Buffer Size > might also be relevant. At 192K, I'd use 4096. > > In any case, if you are still having difficulty, you've found the > workaround for the moment -- the squelch OFF button. > > Let me know if sample rate / DSP buffer size helps. > Hello Warren, I appreciate the comments. I'm running at 48k sample rate with 2048 rx buffer size. If I change to 192k sr the squelch slider seems to operate more like I was expecting, ie. with no or little signal, setting squelch to 0 opens the Rx. That may be how I had it set before, so my old memory may not be failing. However, it really isn't an issue anymore, as I have found the on/off button. I have now had a whopping 2 contacts on FM in the last year or so; usually I am on CW/SSB/JT on UHF and up. It was just that a local had an FM HT with him that would work on 1296, so it was worth a shot for a point. If anyone is planning on using FM more seriously then the note about sample rate would be an important consideration. Tnx for everything. 73 Alf NU8I Phoenix AZ DM33xo From i7swx at yahoo.com Sun Aug 3 08:39:01 2014 From: i7swx at yahoo.com (Giancarlo Moda) Date: Sun, 3 Aug 2014 16:39:01 +0100 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner Message-ID: <1407080341.82109.YahooMailNeo@web172003.mail.ir2.yahoo.com> THE VERY BEST CONGRATULATIONS WARREN, this is the minimum we can say for the Aword you received and more for your "brain" contribution to the Ham and professional fields 73 Gian I7SWX Message: 3 Date: Fri, 01 Aug 2014 00:05:14 -0500 From: Bill Tracey To: HPSDR list Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical ??? Innovation Award winner Message-ID: ??? <201408010505.s71556Dv008606 at mail24c25-2209.carrierzone.com> Content-Type: text/plain; charset="us-ascii"; format=flowed From? http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients? ? ? * The 2014 ARRL Technical Innovation Award went to Warren C.? Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his? research leading to the development of PureSignal, "an adaptive? baseband pre-distortion algorithm used to improve the linearity of? amplifiers and reduce intermodulation distortion products emitted by? software-defined transmitters." Congratulations Warren, and thanks for your excellent contributions! Bill (kd5tfd) -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From getpri at t-online.de Mon Aug 4 05:18:57 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 04 Aug 2014 14:18:57 +0200 Subject: [hpsdr] PowerSDR and OZY In-Reply-To: <53DD9CED.4050900@wpratt.com> References: <53DD4051.5010902@cox.net> <53DD7594.8060509@cox.net> <53DD9CED.4050900@wpratt.com> Message-ID: <53DF7A31.4050102@t-online.de> Hello, what is the latest version of PowerSDR working with OZY? What are the appropriate firmware versions for Mercury and Penylane? 73, Georg, DL2KP --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com From vk5lb at yahoo.com.au Mon Aug 4 07:14:27 2014 From: vk5lb at yahoo.com.au (Dean) Date: Mon, 4 Aug 2014 23:44:27 +0930 Subject: [hpsdr] PwrSDR with Ozy Message-ID: Like Georg, there are many who are happy with Ozy, Mercury and Penelope running an old XP version of PwrSDR. I also would like to hear what people are running as far as XP versions of PwrSDR are concerned. I use 1.19.3.4 by W5WC and it is fine. Penelope 1.2 and Mercury 2.9 with single Rx. However is there a better choice? Cheers Dean. From getpri at t-online.de Mon Aug 4 07:44:14 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 04 Aug 2014 16:44:14 +0200 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: References: Message-ID: <53DF9C3E.8010709@t-online.de> Hi Dean, on my OZY-system, I am running OpenHPSDRmRX-FFT v3.2.1(12/23/13). The question is, if there are newer versions compatibel with OZY. I remember that somebody mentioned on this forum, that this should be the last version for OZY, but I am not shure. 73, Georg, dl2kp Am 04.08.2014 16:14, schrieb Dean: > ***** High Performance Software Defined Radio Discussion List ***** > > Like Georg, there are many who are happy with Ozy, Mercury and Penelope running an old XP version of PwrSDR. I also would like to hear what people are running as far as XP versions of PwrSDR are concerned. I use 1.19.3.4 by W5WC and it is fine. Penelope 1.2 and Mercury 2.9 with single Rx. However is there a better choice? > > Cheers Dean. > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- Internet: in progress ********************************************************************** IMPORTANTE/IMPORTANT CONFIDENCIAL/CONFIDENTIALITY Este mensaje ha sido elaborado ?nicamente para uso de la persona o entidad a la que es remitido, ya que puede contener informaci?n personal, confidencial y de acuerdo a ley no puede ser difundido. Si el lector de este mensaje no es el destinatario se?alado, o la persona responsable para entregar el mensaje a quien est? dirigido, advertimos que cualquier divulgaci?n, retransmisi?n o copia de esta comunicaci?n esta estrictamente prohibida. Si usted ha recibido esta comunicaci?n por error, por favor s?rvase informarlo de inmediato al remitente por correo electr?nico o tel?fono y borrar inmediatamente el mensaje original. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail kann vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ********************************************************************** --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com From ct1izu at sapo.pt Mon Aug 4 08:54:18 2014 From: ct1izu at sapo.pt (ct1izu) Date: Mon, 4 Aug 2014 16:54:18 +0100 Subject: [hpsdr] PwrSDR with Ozy References: Message-ID: <3C85201767F1422FBF481CBE40D6E427@dd52f851956584> Hi Dean My system at CT1IZU is OZY 2.1 Merc 3.1 Penny 1.6 used on a mini ITX D525 (1.8ghz) from Asus running an Nlited XP with SP2. works well but there are some issues on shutdown with it notnot saving data correctly. Shel CT1IZU From ct1izu at sapo.pt Mon Aug 4 08:58:42 2014 From: ct1izu at sapo.pt (ct1izu) Date: Mon, 4 Aug 2014 16:58:42 +0100 Subject: [hpsdr] PwrSDR with Ozy References: Message-ID: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> Dean Too much Vino Tinto Missed the important info pwr SDR Ver 3.2.9 2.23.14 Shel CT1IZU From k5so at valornet.com Mon Aug 4 09:38:47 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 4 Aug 2014 10:38:47 -0600 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> References: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> Message-ID: <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> All, Ozy is still being supported. Ozy works with the current versions of firmware and software on the OpenHPSDR download page (http://openhpsdr.org/download.php). In particular, the current official versions of firmware for Ozy based systems are: PowerSDR_mRX_PS_v3.2.17.0 Ozy v2.7 (included in the PowerSDR_mRX_PS_v3.2.17.0 folder and loads automatically when Ozy is selected as hardware and the initozy11.bat file is edited to point to Ozy_Janus.v27.rbf file) Mercury v3.4 Penelope v1.8 PureSignal is not implemented in any of the Atlas-based systems at the present time so that option in PowerSDR is not available when running Ozy (or Metis). Keep in mind that you may not mix ?old? firmware versions with firmware version that are later than 4May2013 (i.e., Ozy_Janus_v2.5 in the case for Ozy) as a major change for all the Atlas-based boards was made to implement a new I2C bus communications scheme between Ozy(or Metis) and the Mercury/Penelope boards. If you use a version of current firmware in any of the Ozy/Mercury/Penelope boards you must use current firmware in all of the boards (recommended). 73, Joe K5SO From getpri at t-online.de Mon Aug 4 10:32:59 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 04 Aug 2014 19:32:59 +0200 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> References: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> Message-ID: <53DFC3CB.1000502@t-online.de> Thank you Joe and all who responded. Best wishes and 73 Georg, DL2KP Am 04.08.2014 18:38, schrieb Joe Martin K5SO: > ***** High Performance Software Defined Radio Discussion List ***** > > > All, > > Ozy is still being supported. Ozy works with the current versions of firmware and software on the OpenHPSDR download page (http://openhpsdr.org/download.php). > > In particular, the current official versions of firmware for Ozy based systems are: > > PowerSDR_mRX_PS_v3.2.17.0 > > Ozy v2.7 (included in the PowerSDR_mRX_PS_v3.2.17.0 folder and loads automatically when Ozy is selected as hardware and the initozy11.bat file is edited to point to Ozy_Janus.v27.rbf file) > > Mercury v3.4 > > Penelope v1.8 > > PureSignal is not implemented in any of the Atlas-based systems at the present time so that option in PowerSDR is not available when running Ozy (or Metis). > > Keep in mind that you may not mix ?old? firmware versions with firmware version that are later than 4May2013 (i.e., Ozy_Janus_v2.5 in the case for Ozy) as a major change for all the Atlas-based boards was made to implement a new I2C bus communications scheme between Ozy(or Metis) and the Mercury/Penelope boards. > > If you use a version of current firmware in any of the Ozy/Mercury/Penelope boards you must use current firmware in all of the boards (recommended). > > 73, Joe K5SO > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- Internet: in progress ********************************************************************** IMPORTANTE/IMPORTANT CONFIDENCIAL/CONFIDENTIALITY Este mensaje ha sido elaborado ?nicamente para uso de la persona o entidad a la que es remitido, ya que puede contener informaci?n personal, confidencial y de acuerdo a ley no puede ser difundido. Si el lector de este mensaje no es el destinatario se?alado, o la persona responsable para entregar el mensaje a quien est? dirigido, advertimos que cualquier divulgaci?n, retransmisi?n o copia de esta comunicaci?n esta estrictamente prohibida. Si usted ha recibido esta comunicaci?n por error, por favor s?rvase informarlo de inmediato al remitente por correo electr?nico o tel?fono y borrar inmediatamente el mensaje original. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail kann vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ********************************************************************** --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com From wb4gcs at wb4gcs.org Mon Aug 4 15:02:02 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Mon, 04 Aug 2014 18:02:02 -0400 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> References: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> Message-ID: <53E002DA.1080004@wb4gcs.org> Joe: I'm a bit confused by the "keep in mind" paragraph. Does this mean there is some hardware version at which the firmware splits? I have an atlas/ozy/janus system that is probably near original hardware from TAPR. Will the latest firmware you mention below run on that system, or is there some version at which that hardware is no longer supported? Thanks & 73, Jim wb4gcs at amsat.org On 8/4/2014 12:38 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > All, > > Ozy is still being supported. Ozy works with the current versions of firmware and software on the OpenHPSDR download page (http://openhpsdr.org/download.php). > > In particular, the current official versions of firmware for Ozy based systems are: > > PowerSDR_mRX_PS_v3.2.17.0 > > Ozy v2.7 (included in the PowerSDR_mRX_PS_v3.2.17.0 folder and loads automatically when Ozy is selected as hardware and the initozy11.bat file is edited to point to Ozy_Janus.v27.rbf file) > > Mercury v3.4 > > Penelope v1.8 > > PureSignal is not implemented in any of the Atlas-based systems at the present time so that option in PowerSDR is not available when running Ozy (or Metis). > > Keep in mind that you may not mix ?old? firmware versions with firmware version that are later than 4May2013 (i.e., Ozy_Janus_v2.5 in the case for Ozy) as a major change for all the Atlas-based boards was made to implement a new I2C bus communications scheme between Ozy(or Metis) and the Mercury/Penelope boards. > > If you use a version of current firmware in any of the Ozy/Mercury/Penelope boards you must use current firmware in all of the boards (recommended). > > 73, Joe K5SO > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From beford at myfairpoint.net Mon Aug 4 17:31:08 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Mon, 4 Aug 2014 20:31:08 -0400 Subject: [hpsdr] PwrSDR with Ozy Message-ID: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> Jim- The have been no changes in the hardware. Joe's reminder is that if you are using firmware later than 4May13 in one board, you must use firmware later than that date in ALL the boards on the system. This is because some signals were redefined at that time. The hardware hasn't changed, but the purpose of some of the various signal pins did (defined by the firmware, not the hardware). So- don't mix old board firmware and newer firmware in an Atlas-based system. I hope this helps. Bruce/N1RX > Joe: > I'm a bit confused by the "keep in mind" paragraph. Does this mean > there is some hardware version at which the firmware splits? From k5so at valornet.com Mon Aug 4 17:39:01 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 4 Aug 2014 18:39:01 -0600 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> References: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> Message-ID: -ditto. Thanks Bruce, I was out today. 73, Joe K5SO On Aug 4, 2014, at 6:31 PM, Bruce Beford wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Jim- > The have been no changes in the hardware. Joe's reminder is that if you are > using firmware later than 4May13 in one board, you must use firmware later > than that date in ALL the boards on the system. This is because some signals > were redefined at that time. The hardware hasn't changed, but the purpose of > some of the various signal pins did (defined by the firmware, not the > hardware). So- don't mix old board firmware and newer firmware in an > Atlas-based system. > I hope this helps. > Bruce/N1RX > >> Joe: >> I'm a bit confused by the "keep in mind" paragraph. Does this mean >> there is some hardware version at which the firmware splits? > > From wb4gcs at wb4gcs.org Mon Aug 4 18:10:53 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Mon, 04 Aug 2014 21:10:53 -0400 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: References: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> Message-ID: <53E02F1D.1070505@wb4gcs.org> Bruce & Joe: Got it, thanks! FYI, I intend to use Janus/Ozy with a 2-slot Atlas I picked up somewhere to interface to a UHFSDR, which is the IF for my microwave stack: 222, 903,1293, 2304, 3446, 5763 and 10368. The last two will be double-conversion to obey the IF >= 0.1 RF rule. 73, Jim wb4gcs at amsat.org On 8/4/2014 8:39 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > -ditto. Thanks Bruce, I was out today. > > 73, Joe K5SO > > On Aug 4, 2014, at 6:31 PM, Bruce Beford wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Jim- >> The have been no changes in the hardware. Joe's reminder is that if you are >> using firmware later than 4May13 in one board, you must use firmware later >> than that date in ALL the boards on the system. This is because some signals >> were redefined at that time. The hardware hasn't changed, but the purpose of >> some of the various signal pins did (defined by the firmware, not the >> hardware). So- don't mix old board firmware and newer firmware in an >> Atlas-based system. >> I hope this helps. >> Bruce/N1RX >> >>> Joe: >>> I'm a bit confused by the "keep in mind" paragraph. Does this mean >>> there is some hardware version at which the firmware splits? >> > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From carcia at sbcglobal.net Tue Aug 5 08:26:00 2014 From: carcia at sbcglobal.net (FRANCIS CARCIA) Date: Tue, 5 Aug 2014 08:26:00 -0700 Subject: [hpsdr] IMD Message-ID: <1407252360.20359.YahooMailNeo@web184705.mail.ne1.yahoo.com> Hi All, ?As a suffering Giants football fan and a long time chaser of the IMD monster. Congradulations Warren. I will be starting metal work on my QRO SS linear soon now that my slabs of copper have returned from the machine shop. Great Job. Frank WA1GFZ -------------- next part -------------- An HTML attachment was scrubbed... URL: From k2ue at rochester.rr.com Thu Aug 7 15:42:19 2014 From: k2ue at rochester.rr.com (Clyde Washburn) Date: Thu, 7 Aug 2014 18:42:19 -0400 Subject: [hpsdr] Remote Control? Message-ID: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> What is the state of the art in remote control of an OpenHPSDR Tranceiver (such as an Anan) via an internet connection with 1 or 2Mb/s uplink and typical latency? I know OpenHPSDR can be operated via Remote Desktop, but what is the optimal setup for Rx audio to the remote site and Tx audio to the Transceiver, i.e. a full, functioning remote setup? ___________________ Clyde Washburn, K2UE k2ue at ieee.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From n9vv at wowway.com Thu Aug 7 16:11:24 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Thu, 07 Aug 2014 18:11:24 -0500 Subject: [hpsdr] Remote Control? In-Reply-To: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> References: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> Message-ID: <53E4079C.1040203@wowway.com> Hi Clyde, I think the optimal (consultant) answer will cost more than your whole station :-) Here is a list of REMOTE CONTROL programs that are popular. Each claims to be the best. Some have full Audio support: ---------------------------------------------- http://www.remotehams.com/ Any Desk SplashTOP Screen Hero Google Remote Teamviewer Mikogo Parallels Access http://www.dxzone.com/catalog/Contesting/Stations/ (50 entries) http://www.dxzone.com/catalog/Manufacturers/Remote_Control/ (5) http://www.dxzone.com/catalog/Operating_Modes/Remote_Operations/ (9) http://www.dxzone.com/dx6349/internet-remote-base-society.html http://www.dxzone.com/dx13063/remote-controlled-hf-operations.html http://www.dxzone.com/dx24426/remoterig.html UltraVNC TightVNC TinyVNC Skype (for audio) ipSound (discontinued in 2006, but still popular) HPSDR (Android application for Internet Remote for OpenHPSDR written by G0ORX/N6LYT) QtRadio (Win/Lin/MAC remote application for OpenHPSDR written by G0ORX/N6LYT) glSDR - Android QtRadio client with full control written by volunteers for OpenHPSDR ---------------------------------------------- George, K5RIG, and I are currently testing each of these programs to see if any one of them might be suitable. Remote Control of a PC seems to be a very popular topic - and one that has *NOT* been resolved into a manageable set of alternatives. The fellows at RemoteHams.COM have a very attractive setup. So do a dozen others, all at varying prices and kinds of rigs. Flex Radio Systems is going to put Remote Operation on the top of their Developers list this year. They took a show of hands at their Dayton-2014 Banquet and *Remote Operation* was at the top of the list of desired features that their 6000 owners desired. So there is a good list of resources and you can begin your award winning book about "Remote Ham Radio Station Operation" -- or has the ARRL already done that? (hihihi). GL de Ken N9VV On 8/7/2014 5:42 PM, Clyde Washburn wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > What is the state of the art in remote control of an OpenHPSDR > Tranceiver (such as an Anan) via an internet connection with 1 or 2Mb/s > uplink and typical latency? I know OpenHPSDR can be operated via Remote > Desktop, but what is the optimal setup for Rx audio to the remote site > and Tx audio to the Transceiver, i.e. a full, functioning remote setup? > > ___________________ > > Clyde Washburn, K2UE > > k2ue at ieee.org > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From aa8k73 at gmail.com Thu Aug 7 17:14:16 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Thu, 07 Aug 2014 20:14:16 -0400 Subject: [hpsdr] Remote Control? In-Reply-To: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> References: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> Message-ID: <53E41658.9060607@gmail.com> I don't believe that you will be able to transmit CW remotely in the future Clyde. From what I have gleaned about the Generation 2 HPSDR hardware, the telegraph key will be connected to the FPGA on the transmitter board itself as an effort to reduce latency. This is useful if you are physically near the transmitter, but if you have Repetitive Strain Injury ("glass arm") or another disability requiring you use a keyboard instead of wiggling a lever, or want to operate remotely, or to use any type of CW transmitting software, I'm guessing that you would need to tinker some sort of RS-232 type of kludge. On 14-08-07 06:42 PM, Clyde Washburn wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > What is the state of the art in remote control of an OpenHPSDR > Tranceiver (such as an Anan) via an internet connection with 1 > or 2Mb/s uplink and typical latency? I know OpenHPSDR can be > operated via Remote Desktop, but what is the optimal setup for > Rx audio to the remote site and Tx audio to the Transceiver, > i.e. a full, functioning remote setup? > > ___________________ > > Clyde Washburn, K2UE > > k2ue at ieee.org > From pa0tbr at mubo.nl Sat Aug 2 13:56:17 2014 From: pa0tbr at mubo.nl (Ton PA0TBR) Date: Sat, 2 Aug 2014 22:56:17 +0200 Subject: [hpsdr] Compile environement for PowerSDR_HPSDR_mRX_PS Message-ID: Hello, Is Visual Studio 2010 Express the correct environment to compile PowerSDR_HPSDR_mRX_PS? Are there any development notes available? 73, Ton PA0TBR -------------- next part -------------- An HTML attachment was scrubbed... URL: From vk5lb at yahoo.com.au Fri Aug 8 07:46:10 2014 From: vk5lb at yahoo.com.au (Dean PROBERT) Date: Fri, 8 Aug 2014 07:46:10 -0700 Subject: [hpsdr] Downloading Mercury 3.4 In-Reply-To: Message-ID: <1407509170.73138.YahooMailBasic@web120405.mail.ne1.yahoo.com> Thanks for the info I successfully downloaded all files listed below except Mercury V3,4, All I saw was the raw code. How can I download the file? ???????????? From jeffrie at talktalk.net Fri Aug 8 08:42:28 2014 From: jeffrie at talktalk.net (Jeff Cook) Date: Fri, 8 Aug 2014 16:42:28 +0100 Subject: [hpsdr] Downloading Mercury 3.4 Message-ID: <000001cfb31f$5d4736e0$17d5a4a0$@talktalk.net> Dean, try http://svn.tapr.org/repos_sdr_hpsdr/trunk/Mercury/Source/Mercury_V3.4/ Jeff, G0AFQ. -------------- next part -------------- An HTML attachment was scrubbed... URL: From k2xx at swva.net Fri Aug 8 14:19:01 2014 From: k2xx at swva.net (Joe Giacobello, K2XX) Date: Fri, 08 Aug 2014 17:19:01 -0400 Subject: [hpsdr] Hermes Breakout Brd 2-pin Header Message-ID: <53E53EC5.60209@swva.net> In procrastinating my assembly of the breakout board, I seemed to have lost one of the 2-pin PCB headers. If someone has a spare and can put it in an envelope and mail to my CBA, I'd be happy to reimburse by PayPal or whatever payment method works. Thanks for your help. 73, Joe K2XX From aa8k73 at gmail.com Fri Aug 8 20:33:06 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 08 Aug 2014 23:33:06 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/09 Message-ID: <53E59672.6040100@gmail.com> The 9/Aug TeamSpeak mp3 (51 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3510 > or < http://www.hamsdr.com/dnld.aspx > Session text follows <20:41:19> *** You are now talking in channel: "OpenHPSDR" <21:03:28> "Ken N9VV": Nvida Jetson TK1 - Xwindows remote to Windows PC: https://www.youtube.com/watch?v=Z64z_R7MSMU <21:11:12> "Bill - KD5TFD": Yes yes .. TAPR DCC beginning of Sept <21:15:52> "Rick - VE3MM": Rob, Here is the digikey part number for the Hermes extension cable 'A3AKB-1018G-ND'. <21:16:42> "Bill - KD5TFD": AQRP charts on STM32F4 based sdr: https://dl.dropboxusercontent.com/u/14377548/2014%20SummerFest_1.pdf <21:17:04> "Bill - KD5TFD": and: http://stm32-sdr.com/ <21:17:28> "Rob - VE3EW": thanks Rick <21:20:41> "Phil-VK6PH": http://www.ab4oj.com/sdr/apache/anan100d200d_notes.pdf <21:20:45> "Bill - KD5TFD": works ok here <21:21:11> "Ken N9VV": http://www.ab4oj.com/sdr/apache/anan100d200d_notes.pdf FB Here <21:21:38> "Bill - KD5TFD": IE? <21:21:39> "Bill - KD5TFD": IE? <21:21:46> "Bill - KD5TFD": Use a real real browser1 <21:21:49> "Bill - KD5TFD": Use a real real browser! <21:26:37> "Ken N9VV": God! that Keying Envelope looks *GREAT* <21:42:05> "Rick - VE3MM": 73 guys see you next week <21:45:38> "Bill - KD5TFD": sarcasm <22:07:16> "Bill - KD5TFD": so do macs <22:07:20> "Bill - KD5TFD": and linuii's <22:08:02> "Bill - KD5TFD": never do the fix my pc stuff imho From vk6vz at arach.net.au Sat Aug 9 07:42:26 2014 From: vk6vz at arach.net.au (Steve Ireland) Date: Sat, 9 Aug 2014 22:42:26 +0800 Subject: [hpsdr] For Sale: Munin PA kit and Tmate 2 USB SDR Control Console Message-ID: <4F58396271064EC8B49A5020427EA8F8@StevesHPpcPC> G?day I have for sale an HPSDR Munin Power Amplifier kit compiled by Don K3DLW and a WoodBox Radio Tmate2 USB SDR Control Console in ?as new? condition. The Tmate2 has been used with OpenHPSDR W5WC v2.2.12 and all its functionality was available with this software except for the wattmeter. The Munin Power Amplifier Kit is for sale at $200 Australian and has not been opened. The WoodBox Radio Tmate2 is 15 months old, cost 260 Euros (approx. $375 Australian) and is for sale at $300 Australian. Postage on both items will be extra. If you are interested in either item, please email me. Thank you. Vy 73 Steve, VK6VZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ad0es at ad0es.net Sat Aug 9 08:26:15 2014 From: ad0es at ad0es.net (AD0ES) Date: Sat, 9 Aug 2014 09:26:15 -0600 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: Message-ID: Hi, I wrote earlier about my issues getting a metis/mercury working. Finally had success last nite! For the record, I found the following: The mercury as shipped from TAPR had unknown/non-working firmware installed: > Mercury Software version: 255 (0xFF) I upgraded metis to 2.9 and mercury to 3.4. I tried 4 different software packages, only one works. Each was built from sources obtained from their motherload several weeks ago: ghpsdr: seg-faults on startup. ghpsdr3: works. ghpsdr3-Qt: dspserver seg-faults on startup. ghpsdr3-alex: runs, but is "deaf" <<< this was the version I did most of my early testing with Using ubuntu 64-bit 14.04.1 I am going after the seg-faults next, any wisdom on this issue gladly accepted... Steve AD0ES On Jul 23, 2014, at 9:47 AM, AD0ES wrote: > Using ghpsdr3-alex. > > ------------------- > Start hpsdr-server: > /usr/local/bin/hpsdr-server --metis --interface eth0 --10mhzsource mercury --122.88mhzsource mercury > > ... > > Mercury Software version: 255 (0xFF) From k2xx at swva.net Sat Aug 9 08:46:07 2014 From: k2xx at swva.net (Joe Giacobello, K2XX) Date: Sat, 09 Aug 2014 11:46:07 -0400 Subject: [hpsdr] Hermes Breakout Brd 2-pin Header (Got it!) Message-ID: <53E6423F.90801@swva.net> K6GGO kindly offered to send me the part. Many thanks, Joe K2XX In procrastinating my assembly of the breakout board, I seemed to have lost one of the 2-pin PCB headers. If someone has a spare and can put it in an envelope and mail to my CBA, I'd be happy to reimburse by PayPal or whatever payment method works. Thanks for your help. 73, Joe K2XX From cmwalker at mweb.co.za Sat Aug 9 21:40:10 2014 From: cmwalker at mweb.co.za (Conrad Walker) Date: Sun, 10 Aug 2014 06:40:10 +0200 Subject: [hpsdr] PowerSDR & OZY/Mercury/Penelope updating Message-ID: <002c01cfb455$2c0e2ca0$842a85e0$@co.za> Hello all I decided to update my Ozy/Mercury/Penelope HPSDR on WinXP to v2.7/v3.4/v1.8 with PowerSDR v3.2.17.0. Try as I might, I could not flash Mercury with v3.4 firmware via Ozy with USB-Blaster & either Quartus 9.1, 10.1, 12.1 or 13.0. Quartus 9.10 &10.1 gave an error "file Mercury-v3.4.jic corrupted" - unknown argument "Mercury-3.4.cdf", refer to help for legal arguments. Quartus 12.1 and 13.0 gave a "device not ready" error. I was able to flash Mercury v3.3 with Quartus 9.1 & 10.1, and all Quartus versions successfully flashed Penelope v1.8. I was able to run PowerSDR v3.2.17.0 with Mercury v3.3 and Penny v1.7 but found that the CW setup option to use Ozy/Hermes for CW keying no longer exists, and so can no longer run CW with my present setup, My earlier PowerSDR installation worked fine. Any ideas on sorting this out would be most appreciated. 73, Conrad Walker ZS6BQQ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.montefusco at gmail.com Sun Aug 10 11:03:11 2014 From: andrea.montefusco at gmail.com (andrea montefusco) Date: Sun, 10 Aug 2014 20:03:11 +0200 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> Message-ID: On Sun, Aug 10, 2014 at 3:57 PM, AD0ES wrote: > I am aware of cuSDR, but a quick google didn't find the motherload for linux src, any links? As per http://openhpsdr.org/download.php the source are foud in http://svn.tapr.org/repos_sdr_hpsdr/trunk/DL3HVH/cuSDR64/ it requires Qt 4.8. From lu9cbl at gmail.com Sun Aug 10 11:16:00 2014 From: lu9cbl at gmail.com (lu9cbl at gmail.com) Date: Sun, 10 Aug 2014 15:16:00 -0300 Subject: [hpsdr] Starting with HPSDR from Argentina Message-ID: <53E7B6E0.30606@gmail.com> Hi to all... if i want to start with HPSDR, only with the "Atlas Bus", "Mercury Receiver" and the filters "Alex RX" can it works?? or i?m need another "module" for example "Comunication (Ozy, Magister, Metis)"??? Here in Argentina it?s very difficult to buy international ?tems, because we have several filters for import materials... so maybe i can buy the PCBs and make the boards with local components, or buy only the important componentes. I Have a friend that will be going to USA the next month, so he can bring it to me in his briefcase. Thanks in Advance and sorry for my poor english, i hope you can undesrtand me. Mati LU9CBL --- Este mensaje no contiene virus ni malware porque la protecci?n de avast! Antivirus est? activa. http://www.avast.com From wulf at ping.net.au Sun Aug 10 15:16:09 2014 From: wulf at ping.net.au (Berndt Josef Wulf) Date: Mon, 11 Aug 2014 07:46:09 +0930 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> Message-ID: <1407708969.5462.23.camel@Barossa> G'day, A modified version of cuSDR can be downloaded from http://www.ping.net.au/20140126_cuSDR64src.tar.gz It requires QT5 and may not work with the current firmware change, so your mileage may wary. 73, Berndt VK5ABN On Sun, 2014-08-10 at 20:03 +0200, andrea montefusco wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > On Sun, Aug 10, 2014 at 3:57 PM, AD0ES wrote: > > I am aware of cuSDR, but a quick google didn't find the motherload for linux src, any links? > > As per http://openhpsdr.org/download.php the source are foud in > > http://svn.tapr.org/repos_sdr_hpsdr/trunk/DL3HVH/cuSDR64/ > > it requires Qt 4.8. > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From k5so at valornet.com Sun Aug 10 17:52:18 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 10 Aug 2014 18:52:18 -0600 Subject: [hpsdr] Starting with HPSDR from Argentina In-Reply-To: <53E7B6E0.30606@gmail.com> References: <53E7B6E0.30606@gmail.com> Message-ID: <7FC10CDE-148A-426A-AE9C-7935A4EB8C25@valornet.com> Your English is fine, Mati; no problem. Congratulations on thinking of putting together an Atlas-based HPSDR system. In addition to the Atlas bus, Mercury board, and Alex RX filter you will need a board to communicate with your computer; a Metis (ethernet) board or an Ozy (USB) or a Magister (USB); only one of those three computer comm boards, not all three. I recommend Metis, personally, as the ethernet connection is much superior to the USB methods, especially for high data rates that are necessary for wide bandwidths, but Ozy or Magister will work if you decide to use one of them instead. Also, if you use only the Alex RX filter you will have only high pass filtering on your receiver. If you wish to have bandpass filtering you will also need to use the Alex TX filter with the Alex RX filter. The Alex TX filter board provides low pass filtering. Together the Alex RX and Alex TX provide bandpass filtering. Of course, you can run simply a Mercury receiver and a Metis (or Ozy or Magister) on your Atlas bus to have a functional RX radio, without any Alex filters at all, if you wish to try that configuration first before purchasing Alex filter boards. The Alex filters are excellent filter boards and certainly enhance the operations, especially if you are in a location with large out-of-band signals present. I use both TX and RX Alex filters here and find them to be extremely useful to keep from overloading the Mercury receiver when large out-of-band signals are present. Good luck! 73, Joe K5SO On Aug 10, 2014, at 12:16 PM, lu9cbl at gmail.com wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi to all... if i want to start with HPSDR, only with the "Atlas Bus", "Mercury Receiver" and the filters "Alex RX" can it works?? or i?m need another "module" for example "Comunication (Ozy, Magister, Metis)"??? > > Here in Argentina it?s very difficult to buy international ?tems, because we have several filters for import materials... so maybe i can buy the PCBs and make the boards with local components, or buy only the important componentes. I Have a friend that will be going to USA the next month, so he can bring it to me in his briefcase. > > Thanks in Advance and sorry for my poor english, i hope you can undesrtand me. > Mati LU9CBL > > --- > Este mensaje no contiene virus ni malware porque la protecci?n de avast! Antivirus est? activa. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From douglas.adams at me.com Mon Aug 11 04:45:39 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 07:45:39 -0400 Subject: [hpsdr] Radio (Board) Identification Message-ID: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> I would like to propose a small change to the firmware of all of the OpenHPSDR-derived radios. The purpose of this change would be to make the firmware update process more automatic and foolproof. If you look in Metis- How it works_V1.31 you will see that the Discovery packet returns the following: The payload of the UDP/IP reply frame is as follows: <0xEFFE>< Metis MAC Address><49 bytes of 0x00> where Board_ID = 1 byte, 0x00 = Metis, 0x01 = Hermes, 0x02 = Griffin, 0x04 = Angelia, 0x05 = Orion Currently the Board_ID field (one byte) is not very informative. If it says I have a Hermes (0x01) is it a TAPR Hermes, an ANAN-100, an ANAN-100B, an ANAN-100D, etc. Couldn't we use the 8 bits (256 possibilities) in this field to be more specific about the radio? Perhaps to be backward compatible we could reserve the least significant 4 bits for Board ID and use the most significant four bits for a Sub ID indicating which variant of the Board ID is present. If we coupled this change with a "gentlemen's agreement" to name all firmware files in some recognizable way, something like RadioName_vN.M.rbf ( e.g. ANAN100B_v2.4.rbf ) then it would be possible to write a programmer application that would only show you firmware choices appropriate for the radio you are trying to program. The current arrangement seems uninformative and error prone. 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From ad0es at ad0es.net Mon Aug 11 06:33:44 2014 From: ad0es at ad0es.net (AD0ES) Date: Mon, 11 Aug 2014 07:33:44 -0600 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: Message-ID: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> Hi, Using --hermes instead of --metis does indeed cure the deafness, thanx! So for the record, at this point all 4 programs are working: ghpsdr ghpsdr3 ghpsdr3-Qt ghpsdr3-alex Note that I had to make minor changes to get several of them to compile under Ubuntu 14.04.1 (trusty). Mostly issues of header file locations being moved since the last distro. Steve AD0ES On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES wrote: > >> ghpsdr3-alex: runs, but is "deaf" <<< this was the version I did most of my early testing with > > Steve, > please start the hpsdr-server with --hermes instead of --metis and > report if this cure the issue. From kb3omm at gmail.com Mon Aug 11 07:02:59 2014 From: kb3omm at gmail.com (kb3omm) Date: Mon, 11 Aug 2014 10:02:59 -0400 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> Message-ID: Steve, This is great news. Could you email out the changes you made to get each of the programs to build and run, to aid those like myself who cant program but can follow instructions. I have tried previously to get John's three programs to build on newer versions of Qt and Linux without success. Though, ghpsdr3-alex and cuSDR run fine and use them every day. Hermes, Mint 16, Qt4 and 5 73, Kevin On Mon, Aug 11, 2014 at 9:33 AM, AD0ES wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi, > > Using --hermes instead of --metis does indeed cure the deafness, thanx! > > So for the record, at this point all 4 programs are working: > ghpsdr > ghpsdr3 > ghpsdr3-Qt > ghpsdr3-alex > > Note that I had to make minor changes to get several of them to compile > under Ubuntu 14.04.1 (trusty). Mostly issues > of header file locations being moved since the last distro. > > Steve AD0ES > > On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: > > > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES wrote: > > > >> ghpsdr3-alex: runs, but is "deaf" <<< this was the version I > did most of my early testing with > > > > Steve, > > please start the hpsdr-server with --hermes instead of --metis and > > report if this cure the issue. > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 07:12:51 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 08:12:51 -0600 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> Message-ID: <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> Hi Doug, Interesting proposal that deserves some thought. I don?t disagree that our present system is not a perfect arrangement. Keep in mind however that the Board ID is not the only ID parameter ID that is passed in the packets, the actual firmware version is also passed in the packets in a different byte, so that in itself gives more information than you imply, I believe. The board ID is currently used, among other uses perhaps, by the HPSDR Programmer to determine how long to make the time out limit for the EEPROM erase process; some FPGAs are small (e.g., Metis, Mercury, Penny(Lane), Hermes) and erase quickly compared to the larger (Angelia and Orion) FPGAs that take a while to erase. Dave KV0S didn?t think (and I agree) that it was necessary, nor beneficial, to use a long time out delay for erasing FPGAs that didn?t need one. The current ID method works fine for that purpose and needs no additional expansion. While I certainly appreciate that we might want to specify which specific board type is in use (which we do already in a general sense with the current coarse board ID value) the firmware is used in many cases in a variety of hardware configurations of the same board type so it would not be possible for the firmware developer to write the more detailed ID number into the firmware without knowing ahead of time which of the several configurations for the board type is going to be used with the firmware. In the case of Angelia, as one example, the firmware can be used in any radio that uses the Angelia board such as the ANAN-100D or a barefoot Angelia, or an Angelia with an external PA, or with an Angelia with Alex filters, etc. In your suggestion it would seem that all of those different configurations should ideally have a different board ID value written into the firmware. The firmware design would be identical for those units but your suggested approach would seek to use a different board ?ID? for each of them depending upon how the user wanted to use the Angelia board, which the firmware writer would not know. Having a different board ID for each possible board configuration, and thus a different firmware version for each possible configuration, would lead to many versions of Angelia (etc) firmware for a given firmware design needing to be posted for each release and that in itself would undoubtedly prove to be confusing to the users, in my opinion. I haven?t thought through your suggestion completely but these points came immediately to my mind upon reading your message. Maybe others have comments and suggestions that are constructive for this discussion. Thanks for your thoughts on how we might improve things! Perhaps you have already thought through how to address issues such as these. I?m all for whatever makes the mose sense! 73, Joe K5SO On Aug 11, 2014, at 5:45 AM, Doug Adams wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I would like to propose a small change to the firmware of all of the OpenHPSDR-derived radios. The purpose of this change would be to make the firmware update process more automatic and foolproof. > > If you look in Metis- How it works_V1.31 you will see that the Discovery packet returns the following: > The payload of the UDP/IP reply frame is as follows: > <0xEFFE>< Metis MAC Address><49 bytes of 0x00> > > where > > Board_ID = 1 byte, 0x00 = Metis, 0x01 = Hermes, 0x02 = Griffin, 0x04 = Angelia, 0x05 = Orion > > Currently the Board_ID field (one byte) is not very informative. If it says I have a Hermes (0x01) is it a TAPR Hermes, an ANAN-100, an ANAN-100B, an ANAN-100D, etc. Couldn't we use the 8 bits (256 possibilities) in this field to be more specific about the radio? > > Perhaps to be backward compatible we could reserve the least significant 4 bits for Board ID and use the most significant four bits for a Sub ID indicating which variant of the Board ID is present. > > If we coupled this change with a "gentlemen's agreement" to name all firmware files in some recognizable way, something like RadioName_vN.M.rbf ( e.g. ANAN100B_v2.4.rbf ) then it would be possible to write a programmer application that would only show you firmware choices appropriate for the radio you are trying to program. > > The current arrangement seems uninformative and error prone. > > 73?s > Doug - K3TZR > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wully at bluewin.ch Mon Aug 11 09:03:01 2014 From: wully at bluewin.ch (wully) Date: Mon, 11 Aug 2014 18:03:01 +0200 Subject: [hpsdr] CC-Byte0 from fpga to pc Message-ID: <53E8E935.4090808@bluewin.ch> Hi In the Comand-and-Control-Byte 0 from FPGA to PC there are 3 Bits PTT, Dash and Dot. I would like to use at least one of these bits to control an activity. But I don't know, how these bits are fed. From the schematics of METIS and fpga-code I think that Pins 6,7 and 8 on the DB9 connector should be mapped to these (debounced) Bits, but grounding these does not show an effect on the CC-Byte 0. Hardware: Metis (fpga V2.1) Penelope (fpga 1.7) Mercury (fpga 3.3) 1) Which hardware- bits control the Bits 0..2 of CCbyte0 when using the above hardware? 2) Which hardware- bits control if I use Magister instead of Metis (IN0, IN1 and IN2 are also present there). Thank you for your information. 73, hb9epu From g3vbv at blueyonder.co.uk Mon Aug 11 09:07:25 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 11 Aug 2014 17:07:25 +0100 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> Message-ID: <53E8EA3D.9060807@blueyonder.co.uk> I modified GHPSDR3-Qt/FULL/KV0S/KV0S.pro, adding the Qt include PATHS INCLUDEPATH += . \ /usr/include/QtMultimedia /usr/include/QtNetwork /usr/include/QtXml \ ghpsdr3/DRadio \ griffin/griffinID \ Missing file frequencysender.h:- IQt-Radio-Programs/QtHPSDRServer/client -I. -I. -o receivethread.o hpsdr-programmers/Programmer/receivethread.cpp In file included from hpsdr-programmers/Programmer/receivethread.cpp:37:0: ghpsdr3/DRadio/mainwindow.h:5:29: fatal error: frequencysender.h: No such file or directory #include "frequencysender.h" ^ compilation terminated. make: *** [receivethread.o] Error 1 73 ... Sid. On 11/08/14 15:02, kb3omm wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > Steve, This is great news. > > Could you email out the changes you made to get each of the programs > to build and run, to aid those like myself who cant program but can > follow instructions. > > I have tried previously to get John's three programs to build on newer > versions of Qt and Linux without success. > > Though, ghpsdr3-alex and cuSDR run fine and use them every day. > > Hermes, Mint 16, Qt4 and 5 > > 73, Kevin > > > On Mon, Aug 11, 2014 at 9:33 AM, AD0ES > wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi, > > Using --hermes instead of --metis does indeed cure the deafness, > thanx! > > So for the record, at this point all 4 programs are working: > ghpsdr > ghpsdr3 > ghpsdr3-Qt > ghpsdr3-alex > > Note that I had to make minor changes to get several of them to > compile under Ubuntu 14.04.1 (trusty). ? Mostly issues > of header file locations being moved since the last distro. > > Steve ? AD0ES > > On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: > > > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES > wrote: > > > >> ? ? ? ? ghpsdr3-alex: ? runs, but is "deaf" <<< this was > the version I did most of my early testing with > > > > Steve, > > please start the hpsdr-server with --hermes instead of --metis and > > report if this cure the issue. > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 09:38:40 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 10:38:40 -0600 Subject: [hpsdr] PowerSDR & OZY/Mercury/Penelope updating In-Reply-To: <002c01cfb455$2c0e2ca0$842a85e0$@co.za> References: <002c01cfb455$2c0e2ca0$842a85e0$@co.za> Message-ID: <6282414A-39D6-4B4A-B895-F74A508BACD3@valornet.com> Hi Conrad, I haven?t seen any response on the list for your inquiry so I?ll respond. I wonder if you are using the current USBBinaries-Blaster folder? It can be found at http://svn.tapr.org/repos_sdr_hpsdr/trunk/USBBlaster-Binaries/ If not, please get the latest folder and give those files a try. Even if you do already have the latest USBBlaster-Binaries folder the message below seems to indicate that the files may be corrupted somehow. Therefore, in this case too, I?d download a fresh copy of the USBBlaster-Binaries folder and try them to see if that will work for you. I just checked the current USBBlaster-Binaries/Program-Mercury-EPCS16.bat file in the USBBlaster-Binaries folder to verify that it has options for the current Altera Quartus II v13.0 version and Mercury_v3.4; it does, so it should work I would think. 73, Joe K5SO On Aug 9, 2014, at 10:40 PM, Conrad Walker wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hello all > > I decided to update my Ozy/Mercury/Penelope HPSDR on WinXP to v2.7/v3.4/v1.8 with PowerSDR v3.2.17.0. > > Try as I might, I could not flash Mercury with v3.4 firmware via Ozy with USB-Blaster & either Quartus 9.1, 10.1, 12.1 or 13.0. Quartus 9.10 &10.1 gave an error "file Mercury-v3.4.jic corrupted" - unknown argument "Mercury-3.4.cdf", refer to help for legal arguments. Quartus 12.1 and 13.0 gave a "device not ready" error. I was able to flash Mercury v3.3 with Quartus 9.1 & 10.1, and all Quartus versions successfully flashed Penelope v1.8. > > I was able to run PowerSDR v3.2.17.0 with Mercury v3.3 and Penny v1.7 but found that the CW setup option to use Ozy/Hermes for CW keying no longer exists, and so can no longer run CW with my present setup, My earlier PowerSDR installation worked fine. > > Any ideas on sorting this out would be most appreciated. > > 73, > > Conrad Walker ZS6BQQ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wully at bluewin.ch Mon Aug 11 09:44:50 2014 From: wully at bluewin.ch (wully) Date: Mon, 11 Aug 2014 18:44:50 +0200 Subject: [hpsdr] CC-Byte0 from fpga to pc In-Reply-To: <53E8E935.4090808@bluewin.ch> References: <53E8E935.4090808@bluewin.ch> Message-ID: <53E8F302.2070501@bluewin.ch> Hi I have checked the software and found an error in my code: the ccbyte0 brings the IN0,IN1,IN2-States from all boards, that support these. 73, hb9epu On 11.08.2014 18:03, wully wrote: > Hi > > In the Comand-and-Control-Byte 0 from FPGA to PC there are 3 Bits PTT, > Dash and Dot. > > I would like to use at least one of these bits to control an activity. > But I don't know, how these bits are fed. > From the schematics of METIS and fpga-code I think that Pins 6,7 and 8 > on the DB9 connector should be mapped to these (debounced) Bits, > but grounding these does not show an effect on the CC-Byte 0. > > Hardware: > Metis (fpga V2.1) > Penelope (fpga 1.7) > Mercury (fpga 3.3) > > 1) Which hardware- bits control the Bits 0..2 of CCbyte0 when using > the above hardware? > 2) Which hardware- bits control if I use Magister instead of Metis > (IN0, IN1 and IN2 are also present there). > > Thank you for your information. > > 73, hb9epu > > > > From douglas.adams at me.com Mon Aug 11 10:00:50 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 13:00:50 -0400 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> Message-ID: Joe, Thank you for your comments. Does the firmware file contain the byte representing the Device ID or is it somehow derived by the firmware from the hardware of the board? I would like to be able to prevent (or maybe just warn) a user from selecting an inappropriate firmware file for their Radio. With the current Board ID I can identify the "sub-type" of the Radio (i.e. Metis, Hermes, Angelia, etc). If the firmware file contains the Device ID (maybe someone can tell me how to find that byte in the firmware file), I could compare that to the Device ID of the Radio. Matching those would get me part way to my intent. I'm in the process of adding Firmware Programming into my own SDR app (on a Mac). If you can picture it, I have two lists on screen; a list of the Radios my app can see on the networks attached to the Mac and a list of the Firmware files it can find at various places on the Mac. I expect the user to select a Radio from the first list and a Firmware file from the second list at which point the Erase & Program button is enabled. The question I've been unable to answer is; how to know that I am about to program my Radio with a Firmware version that is somehow inappropriate? There is another layer to Radio (not Board) identification. As you point out, any one firmware file might be used in multiple Radios. Unfortunately, two Radios with the same Board ID might require different firmware. You also mentioned that the firmware version is reported in the protocol. I agree however I believe some versions are being distinguished by placing a letter after the version (e.g. Hermes v2.9b) and I don't believe the suffix is retained or reported back. As far as naming the firmware files goes, each of us can do that ourselves after downloading them but it would be nice if there was an agreed upon naming scheme being used by the creators of the files. It might avoid some errors. Partly my motivation is simply "getting it right" but partly it's because I also see entries in this list where someone has gotten the wrong firmware installed. On Aug 11, 2014, at 10:12 AM, Joe Martin K5SO wrote: > Hi Doug, > > Interesting proposal that deserves some thought. I don?t disagree that our present system is not a perfect arrangement. > > Keep in mind however that the Board ID is not the only ID parameter ID that is passed in the packets, the actual firmware version is also passed in the packets in a different byte > ....... > > While I certainly appreciate that we might want to specify which specific board type is in use (which we do already in a general sense with the current coarse board ID value) the firmware is used in many cases in a variety of hardware configurations > ....... > > 73, Joe K5SO > 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 10:15:38 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 11:15:38 -0600 Subject: [hpsdr] CC-Byte0 from fpga to pc In-Reply-To: <53E8F302.2070501@bluewin.ch> References: <53E8E935.4090808@bluewin.ch> <53E8F302.2070501@bluewin.ch> Message-ID: Okay, very good. I just checked the behavior of bit 2 in the C0 command bytes coming from Metis, using current firmware in all boards, and it responds fine to the DB9 input pin grounding for DASH. I don?t know why you?d want to use old firmware/software but maybe you have a reason to do so. I did not take time to load old version of firmware for these tests. Current firmware is: Metis_v2.9 Mercury_v3.4 Penelope_v1.8 Current software for PSDR is: PowerSDR_mRX_PS_v3.1.17.0 Thanks for updating your situation! 73, Joe K5SO On Aug 11, 2014, at 10:44 AM, wully wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > I have checked the software and found an error in my code: the ccbyte0 brings the IN0,IN1,IN2-States from all boards, that support these. > > 73, hb9epu > > > On 11.08.2014 18:03, wully wrote: >> Hi >> >> In the Comand-and-Control-Byte 0 from FPGA to PC there are 3 Bits PTT, Dash and Dot. >> >> I would like to use at least one of these bits to control an activity. But I don't know, how these bits are fed. >> From the schematics of METIS and fpga-code I think that Pins 6,7 and 8 on the DB9 connector should be mapped to these (debounced) Bits, >> but grounding these does not show an effect on the CC-Byte 0. >> >> Hardware: >> Metis (fpga V2.1) >> Penelope (fpga 1.7) >> Mercury (fpga 3.3) >> >> 1) Which hardware- bits control the Bits 0..2 of CCbyte0 when using the above hardware? >> 2) Which hardware- bits control if I use Magister instead of Metis (IN0, IN1 and IN2 are also present there). >> >> Thank you for your information. >> >> 73, hb9epu >> From kb3omm at gmail.com Mon Aug 11 10:41:31 2014 From: kb3omm at gmail.com (kb3omm) Date: Mon, 11 Aug 2014 13:41:31 -0400 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <53E8EA3D.9060807@blueyonder.co.uk> References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> <53E8EA3D.9060807@blueyonder.co.uk> Message-ID: Steve, Sid, Thanks for your notes. I will try these and report back 73, Kevin On Mon, Aug 11, 2014 at 12:07 PM, Sid Boyce wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > I modified GHPSDR3-Qt/FULL/KV0S/KV0S.pro, adding the Qt include PATHS > INCLUDEPATH += . \ > /usr/include/QtMultimedia /usr/include/QtNetwork > /usr/include/QtXml \ > ghpsdr3/DRadio \ > griffin/griffinID \ > > Missing file frequencysender.h:- > IQt-Radio-Programs/QtHPSDRServer/client -I. -I. -o receivethread.o > hpsdr-programmers/Programmer/receivethread.cpp > In file included from hpsdr-programmers/Programmer/receivethread.cpp:37:0: > ghpsdr3/DRadio/mainwindow.h:5:29: fatal error: frequencysender.h: No such > file or directory > #include "frequencysender.h" > ^ > compilation terminated. > make: *** [receivethread.o] Error 1 > 73 ... Sid. > > On 11/08/14 15:02, kb3omm wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > > > > Steve, This is great news. > > Could you email out the changes you made to get each of the programs to > build and run, to aid those like myself who cant program but can follow > instructions. > > I have tried previously to get John's three programs to build on newer > versions of Qt and Linux without success. > > Though, ghpsdr3-alex and cuSDR run fine and use them every day. > > Hermes, Mint 16, Qt4 and 5 > > 73, Kevin > > > On Mon, Aug 11, 2014 at 9:33 AM, AD0ES wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi, >> >> Using --hermes instead of --metis does indeed cure the deafness, thanx! >> >> So for the record, at this point all 4 programs are working: >> ghpsdr >> ghpsdr3 >> ghpsdr3-Qt >> ghpsdr3-alex >> >> Note that I had to make minor changes to get several of them to compile >> under Ubuntu 14.04.1 (trusty). ? Mostly issues >> of header file locations being moved since the last distro. >> >> Steve ? AD0ES >> >> On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: >> >> > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES wrote: >> > >> >> ? ? ? ? ghpsdr3-alex: ? runs, but is "deaf" <<< this was the >> version I did most of my early testing with >> > >> > Steve, >> > please start the hpsdr-server with --hermes instead of --metis and >> > report if this cure the issue. >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > -- > 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 > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 11:15:47 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 12:15:47 -0600 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> Message-ID: Doug, RR, understood; but I don?t entirely agree with your assessment of the present situation. Let me respond to each of the issues to which I refer: 1) Answering your question: Yes, the firmware Verilog design contains the DEVICE ID number in the Verilog code itself; it?s coded into the ethernet packets directly. For example, the hardware ID value for Angelia is hardcoded in the Angelia Verilog design into line1059 of the TX_MAC module in the Verilog design. It?s done similarly, if not identically, in the Verilog firmware designs for all the other HPSDR and ANAN-series boards. 2) I see what it is that you are trying to accomplish and it?s an admirable goal I think. It seems to me (with one exception which I will mention next) that the current hardware ID scheme works just fine for identifying the hardware to match with firmware. I am not aware of any firmware named for a hardware board that does not work in that board, regardless of the configuration of the board (the exception I mentioned notwithstanding). Namely, the hardware ID specifies whether the board is a Metis, Hermes, Griffin, Angelia, or Orion. The user should be aware, for example, which board his radio uses and therefore be able to match the board with the necessary firmware since the firmware filename includes the board name with which it is intended to be used. 3) The exception I mention above has to do with the minor difference in Apache Labs versions of firmware that are labeled ?b? suffix, in which the switch point for 10m filters is different from radios using Alex filters. The operational effect of not using a ?b? version in an ANAN radio that has the PA filters is perhaps a bit lower maximum output power on 10m; that?s it. Otherwise the firmware will work just fine. 4) I agree with you that labeling firmware versions with a ?b? suffix is not a good idea at all because the firmware version reporting protocol within firmware does not allow for letters in the firmware version numbers. In my opinion, an entirely new firmware version number (using numbers exclusively, no sub-letters) should be used, even for that small distinction of the 10m filter switch point. I always avoid using letter suffix nomenclature in released firmware versions, because there is no way to distinguish those ?modified? versions from the original versions by looking at the version numbers being reported by the firmware. I much prefer to use an entirely different firmware version number which is acceptable in the current firmware version number protocol (no letters) and easily distinguishable from anything else by simply looking at the firmware version number that is reported by the firmware. With regard to loading the wrong firmware, if someone loads Metis code into Angelia, as one example, there really is no excuse for doing it as the Metis firmware has the ?Metis? name in the firmware filename. It?s always a recoverable event in any case, even if it happens. Granted you must use a blaster cable to recover but that?s the penalty you SHOULD have to pay for not reading the name, in my view. Next time you will read it. Further, quite simply, if you own an ANAN radio and don?t even know what major board type the radio has in it (Hermes, Angelia, or Orion) you likely are not well suited to be a user of that radio, as you?re going to have tremendous difficulties operating the thing and updating its firmware later on; my personal opion, of course. I understand your desire to make your code bulletproof against ignorance, and I applaud the attempt, but I think we can go overboard in that area. There are some people who are simply not well suited to using SDR, as I have come to appreciate. I used to think otherwise but sadly now I don?t. These are complex, high-performance radios and they need marginally compentent users at least in order to be able to realize the advantages that they can offer. Again, my opion. You?re all welcome to have a different opinion, if you wish. 73, Joe K5SO From douglas.adams at me.com Mon Aug 11 11:31:54 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 14:31:54 -0400 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> Message-ID: <5C402B1B-058D-4861-A53C-B46863D74269@me.com> Joe (et all), Well stated, let me summarize my take away. 1. If I match the name in the firmware file name (e.g. "Hermes", "Metis", "Angelia") with the Board ID from my Radio (translated to the appropriate string) I will never load a non-operative firmware (it may have minor issues such as the filter control but it will work). 2. We should suggest to those who create firmware files that they only use numbered versions (i.e. no suffixes). I can live with #1, I'll implement it in my code as a Warning (to keep me from doing something dumb, I don't own a Blaster, yet). I'm not sure how we get people to comply with #2. On Aug 11, 2014, at 2:15 PM, Joe Martin K5SO wrote: > Doug, > > RR, understood; but I don?t entirely agree with your assessment of the present situation. Let me respond to each of the issues to which I refer: > > .... > These are complex, high-performance radios and they need marginally compentent users at least in order to be able to realize the advantages that they can offer. Again, my opion. You?re all welcome to have a different opinion, if you wish. > > 73, Joe K5SO > > 73?s Doug - K3TZR From k5so at valornet.com Mon Aug 11 11:46:59 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 12:46:59 -0600 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <5C402B1B-058D-4861-A53C-B46863D74269@me.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> <5C402B1B-058D-4861-A53C-B46863D74269@me.com> Message-ID: <87FDB69E-648D-4E93-953D-89C99190F44A@valornet.com> Doug, Yes. I think #2 will take care of itself given the amount of angst it has caused already, hihi. We learn as we go. 73, Joe K5SO On Aug 11, 2014, at 12:31 PM, Doug Adams wrote: > Joe (et all), > > Well stated, let me summarize my take away. > > 1. If I match the name in the firmware file name (e.g. "Hermes", "Metis", "Angelia") with the Board ID from my Radio (translated to the appropriate string) I will never load a non-operative firmware (it may have minor issues such as the filter control but it will work). > > 2. We should suggest to those who create firmware files that they only use numbered versions (i.e. no suffixes). > > I can live with #1, I'll implement it in my code as a Warning (to keep me from doing something dumb, I don't own a Blaster, yet). I'm not sure how we get people to comply with #2. > > > On Aug 11, 2014, at 2:15 PM, Joe Martin K5SO wrote: > >> Doug, >> >> RR, understood; but I don?t entirely agree with your assessment of the present situation. Let me respond to each of the issues to which I refer: >> >> .... > >> These are complex, high-performance radios and they need marginally compentent users at least in order to be able to realize the advantages that they can offer. Again, my opion. You?re all welcome to have a different opinion, if you wish. >> >> 73, Joe K5SO >> >> > > 73?s > Doug - K3TZR > > > > > > From douglas.adams at me.com Mon Aug 11 11:48:50 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 14:48:50 -0400 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> Message-ID: <1B7A282F-FFC2-4C41-B1BC-B5347FF2DD1A@me.com> Thanks Dave, Although I haven't done any C++ in years I looked through the code and got the idea. I see that you are doing what I've decided to do (see my last post), making sure the firmware file name jives with the Board ID. I also found the definitions for the Max Timeouts for each board which I'll incorporate into my programmer. Hopefully I won't brick my radio in the process of debugging my code. On Aug 11, 2014, at 2:22 PM, Dave Larsen wrote: > Doug -- > > in the HPSDRProgrammer the code you are looking for is in http://svn.tapr.org/repos_sdr_hpsdr/trunk/KV0S/hpsdr-programmers/HPSDRProgrammerV2-nopcap/mainwindow.cpp in the browse function. > > The current HPSDRProgrammer talks to the old firmware to load the flash memory. You are right that the a and b are not kept. Joe and Phil produce most of the firmware for these boards and the naming is up to them. Internally the store the board type and the firmware version is all that is stored and read. > > Part of the issue is some of this changes the bootloader firm, which is install at manufacture not not changed. This is the recover system. we have no causal system for users to replace the bootloader. > > Hope this helps > > Dave KV0S > 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vbv at blueyonder.co.uk Mon Aug 11 13:54:18 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 11 Aug 2014 21:54:18 +0100 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> <53E8EA3D.9060807@blueyonder.co.uk> Message-ID: <53E92D7A.3090004@blueyonder.co.uk> Hi Steve and Kevin, This time instead of the KV0S svn I used "svn co http://svn.tapr.org/repos_sdr_hpsdr/trunk/N6LYT/Qt" which built without changes slipstream:/usr/src/Qt/trunk # ls -l bin total 2484 -rwxr-xr-x 1 root root 1481425 Aug 11 20:33 QtDSPServer -rwxr-xr-x 1 root root??? 396047 Aug 11 20:32 QtHPSDRServer -rwxr-xr-x 1 root root??? 663150 Aug 11 20:34 QtRadio Building on openSUSE which uses lib64 instead of lib. libusb-1.0 is in /usr/include. Makefile changes ========== ghpsdr ---------- INCLUDES=-I. -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/gdk-pixbuf-2.0\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/atk-1.0 -I/usr/include/cairo\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/pango-1.0 -I/usr/include/glib-2.0\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/freetype2 -I/usr/include/libpng12 \ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/libusb-1.0 Exploded and built DttSP.tar.gz in the ghpsdr directory LIBS=-L. -L/usr/src/openHPSDR/ghpsdr/DttSP -lDttSP -lpthread -lusb-1.0\ ??? ??? ??? ??? -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0\ ??? ??? ??? ??? -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lz\ ??? ??? ??? ??? -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lfftw3f slipstream:/usr/src/openHPSDR/ghpsdr # ls -l bin total 1336 -rwxr-xr-x 1 root root 1126746 Aug 11 20:47 ghpsdr -rwxr-xr-x 1 root root??? ??? ??? ??? 256 Aug 11 20:40 ghpsdr.sh -rw-r--r-- 1 root root??? ??? 21032 Aug 11 20:40 icon.png -rwxr-xr-x 1 root root??? ??? ??? 1343 Aug 11 20:40 initozy drwxr-xr-x 2 root root??? ??? ??? 4096 Aug 11 20:40 linux64 -rwxr-xr-x 1 root root??? ??? 14555 Aug 11 20:40 loadFPGA -rwxr-xr-x 1 root root??? ??? 14324 Aug 11 20:40 loadFW drwxr-xr-x 2 root root??? ??? ??? 4096 Aug 11 20:40 mac -rw-r--r-- 1 root root??? ??? 21862 Aug 11 20:40 ozyfw-sdr1k.hex -rw-r--r-- 1 root root??? 121875 Aug 11 20:40 Ozy_Janus.rbf -rwxr-xr-x 1 root root??? ??? 14687 Aug 11 20:40 write_i2c ghpsdr3-alex always has been OK. 73 ... Sid. -- 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 From andrea.montefusco at gmail.com Mon Aug 11 14:04:08 2014 From: andrea.montefusco at gmail.com (andrea montefusco) Date: Mon, 11 Aug 2014 23:04:08 +0200 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <1407708969.5462.23.camel@Barossa> References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> <1407708969.5462.23.camel@Barossa> Message-ID: On Aug 11, 2014 12:16 AM, "Berndt Josef Wulf" wrote: > > G'day, > > A modified version of cuSDR can be downloaded from > >http://www.ping.net.au/20140126_cuSDR64src.tar.gz > > It requires QT5 and may not work with the current firmware change, so > your mileage may wary. Hi Berndt, That is a good news, especially for people trying to use cuSDR on Jetson board: together with Ken N9VV we compiled the original cuSDR but we didn't manage to achieve a proper working with the Qt 4.x. In any case, I just compiled your code with qt 5.3 on Ubuntu 12.04 (i5) and it works well (Metis 2.8, Mercury 3.4). *am* -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vbv at blueyonder.co.uk Mon Aug 11 17:29:04 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Tue, 12 Aug 2014 01:29:04 +0100 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> <53E8EA3D.9060807@blueyonder.co.uk> Message-ID: <53E95FD0.4000106@blueyonder.co.uk> Hi Steve and Kevin, Instead of the KV0S svn I use "svn co http://svn.tapr.org/repos_sdr_hpsdr/trunk/N6LYT/Qt" built without changes /usr/src/Qt/trunk # ls -l bin total 2484 -rwxr-xr-x 1 root root 1481425 Aug 11 20:33 QtDSPServer -rwxr-xr-x 1 root root?????? 396047 Aug 11 20:32 QtHPSDRServer -rwxr-xr-x 1 root root?????? 663150 Aug 11 20:34 QtRadio Building on openSUSE which uses lib64. libusb-1.0 is in /usr/include. Makefile changes ========== ghpsdr ---------- INCLUDES=-I. -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include\ -I/usr/include/gdk-pixbuf-2.0\ -I/usr/include/atk-1.0 -I/usr/include/cairo\ -I/usr/include/pango-1.0 -I/usr/include/glib-2.0\ -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1\ -I/usr/include/freetype2 -I/usr/include/libpng12 \ -I/usr/include/libusb-1.0 Built DttSP.tar.gz in ghpsdr directory LIBS=-L. -L/usr/src/openHPSDR/ghpsdr/DttSP -lDttSP -lpthread -lusb-1.0\ -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0\ -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lz\ -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lfftw3f slipstream:/usr/src/openHPSDR/ghpsdr # ls -l bin/ghpsdr -rwxr-xr-x 1 root root 1126746 Aug 11 20:47 ghpsdr ghpsdr3-alex always has been OK. 73 ... Sid. -- 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 From g3vbv at blueyonder.co.uk Mon Aug 11 17:39:58 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Tue, 12 Aug 2014 01:39:58 +0100 Subject: [hpsdr] 20140126_cuSDR64src In-Reply-To: References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> <1407708969.5462.23.camel@Barossa> Message-ID: <53E9625E.5070203@blueyonder.co.uk> No problems on openSUSE x86_64, built with Qt-5.3.1. 73 ... Sid. On 11/08/14 22:04, andrea montefusco wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > > On Aug 11, 2014 12:16 AM, "Berndt Josef Wulf" > wrote: > > > > G'day, > > > > A modified version of cuSDR can be downloaded from > > > >http://www.ping.net.au/20140126_cuSDR64src.tar.gz > > > > It requires QT5 and may not work with the current firmware change, so > > your mileage may wary. > > -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vbv at blueyonder.co.uk Tue Aug 12 12:46:15 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Tue, 12 Aug 2014 20:46:15 +0100 Subject: [hpsdr] 20140126_cuSDR64src In-Reply-To: <53E9625E.5070203@blueyonder.co.uk> References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> <1407708969.5462.23.camel@Barossa> <53E9625E.5070203@blueyonder.co.uk> Message-ID: <53EA6F07.8060000@blueyonder.co.uk> Hi Andrea, Just for fun I built it on the ODROID-U3 but have not got around to testing it. root at odroidu3:/a1/ANDREA/cuSDR64# file bin/cuSDR64 bin/cuSDR64: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=ad66531161d9dd1be3a83e4720c1436343b867ef, not stripped root at odroidu3:/a1/ANDREA/cuSDR64# cuSDR32 modified and built with qt-5.3.1 should also be no problem. 73 ... Sid. On 12/08/14 01:39, Sid Boyce wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > No problems on openSUSE x86_64, built with Qt-5.3.1. > 73 ... Sid. > > On 11/08/14 22:04, andrea montefusco wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> >> >> >> On Aug 11, 2014 12:16 AM, "Berndt Josef Wulf" > > wrote: >> > >> > G'day, >> > >> > A modified version of cuSDR can be downloaded from >> > >> >http://www.ping.net.au/20140126_cuSDR64src.tar.gz >> > >> > It requires QT5 and may not work with the current firmware change, so >> > your mileage may wary. >> >> > > -- > 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 > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gokoyev+k3it at gmail.com Thu Aug 14 07:14:26 2014 From: gokoyev+k3it at gmail.com (k3it) Date: Thu, 14 Aug 2014 10:14:26 -0400 Subject: [hpsdr] Updates to the Skimmer server interface DLL v14.8.13 Message-ID: An updated version of HermesIntf.dll Skimmer server interface for HPSDR is available at *https://sourceforge.net/projects/hermesintf/files/ * new h/w support: - Afedri SDR-net in HPSDR emulation mode (firmware 228e and higher) - N1GP RTL_hpsdr (see https://github.com/n1gp/rtl_hpsdr ) - up to seven receivers in Hermes depending on the firmware revision. Support of the latest v2.9 firmware (4 rcvrs) - additonal HPSDR variants (Angelia, Metis, etc) increased logging level in HermesIntf_log_file.txt Supported sample rates/receivers: 48/96/192 Khz Hermes: - Firmware version *1.8* (download from the dxatlas.com web site) - 7 receivers - Firmware version 2.4,2.5 - 5 receivers - Firmware version 2.9 - 4 receivers - Other fw revisions: defaults to 4 receivers Angelia: - 7 receivers Metis: - 4 receivers N1GP RTL dongle in HPSDR emulation mode: - up to 8 receivers, depending on the number of connected dongles Afedri SDR-NET single and dual channel in HPSDR emulation mode: - 1 or 2 receivers Please email if you run into any problems 73! Vasiliy K3IT -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrospopo at sbcglobal.net Mon Aug 11 09:38:50 2014 From: jrospopo at sbcglobal.net (Jim Rospopo) Date: Mon, 11 Aug 2014 11:38:50 -0500 Subject: [hpsdr] Newbie Question on computer and Munin Message-ID: <023201cfb582$bb967750$32c365f0$@sbcglobal.net> Newbie question, I just got the rest of the cards for my HPSDR. I was wondering what are the minimum requirements for the computer. I'll most likely be using the PowerSDR software or I may use it on my iMac with those programs. Are these programs optimized for the intel processors or will the AMD processors work equally well ? Also any minimum RAM requirements and or processor speeds ? Also, is there any more information on the Munin PA ? I know there was a group buy a while back. Are any kits still available from that buy. I also heard that TAPR was thinking of offering it as a kit. Is there any more information on that front. I'm sure as I proceed I'll have more questions. Excited to get this put together and operating. 73's Jim KE4CON -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa8k73 at gmail.com Fri Aug 15 19:23:24 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 15 Aug 2014 22:23:24 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/16 Message-ID: <53EEC09C.2040106@gmail.com> The 16/Aug TeamSpeak mp3 (61 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3511 > or < http://www.hamsdr.com/dnld.aspx > Only silence truncation editing was done on this recording. From phil at pharman.org Sun Aug 17 01:36:07 2014 From: phil at pharman.org (Phil Harman) Date: Sun, 17 Aug 2014 16:36:07 +0800 Subject: [hpsdr] Hermes manual update Message-ID: <33210BB5CEBB48C2BA7FC92CBE75EE0F@ShackPC2> All, There is an update to the Hermes User Manual (V1.18) available from: http://openhpsdr.org/documents.php This contains additional information on the use of J17 when an external supply is used. Thanks to Rob, VE3EW, for the updated information. 73 Phil...VK6PH --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at vspl.co.uk Sun Aug 17 09:37:01 2014 From: chris at vspl.co.uk (Chris Smith) Date: Sun, 17 Aug 2014 17:37:01 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 Message-ID: <20140817163704.A6AAD48278@diego.dreamhost.com> Hi Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. Eventually cuSDR64 built and I could run it on the TK1 It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? Exciting to be able to use my TK1 in anger. Cheers & 73 Chris G4NUX From wulf at ping.net.au Sun Aug 17 14:02:25 2014 From: wulf at ping.net.au (Berndt Josef Wulf) Date: Mon, 18 Aug 2014 06:32:25 +0930 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <20140817163704.A6AAD48278@diego.dreamhost.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <1408309345.3501.6.camel@Barossa> G'day Chris, The -j4 option defines the number of threads being used for the build process in this case 4. I use -j n where n is number of CPU cores available on the system +1. It significantly speeds up the building process on multi-core systems. cuSDR's CPU load is generally high including Intel based *nix systems. I never looked into this, as I still hoping for an updated version from Hermann. The chief reasons for me using cuSDR is that it runs under Linux/NetBSD and the many features that made using it a pleasure. 73, Berndt VK5ABN On Sun, 2014-08-17 at 17:37 +0100, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my > recently acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for > some years now, building the libraries from sources under Fedora Linux > & OSX. I found the published build instructions using git a bit > longwinded but eventually succeeded. Does anyone know what the -j4 > option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after > changing the symlink in /usr/bin so that qmake pointed to the Qt-5 > version in /usr/local/Qt-5/bin I could run qmake at the top level of > cuSDR to bring the Makefile up to date. I didn't do a make clean so > some .o files reported "wrong file type" but removing the 3 offending > .o files led me to the next problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 > https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz > ) and apart from configure requiring a couple of qualifiers ( > ./configure --enable-single --enable-shared ) that library built and > installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run > cuSDR on any platform before) but everything appeared to be working. My > Atlas hardware was correctly reported along with ancient f/w versions > and I could hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a > roller wheel in the shack so the only way I seem to be able to tune is > to drag the frequency bar under the display left-right. That is far too > crude to tune an individual QSO but got me some audio recognisable as a > contact. > > One thing which alarms me slightly is that the CPU usage reported is in > the range 152-175% I assume that is reporting that more than one core > (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web > page: http://openhpsdr.org Archives: > http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From g3vbv at blueyonder.co.uk Sun Aug 17 15:12:17 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Sun, 17 Aug 2014 23:12:17 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <20140817163704.A6AAD48278@diego.dreamhost.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <53F128C1.7040900@blueyonder.co.uk> Hi Chris, As mentioned - The first impression is that the TK1 is 64-bit, but it is quad-core 32-bit. It's still a powerful beast, CUDA ensures that. The next version apparently due later this year is dual-core 64-bit. 20140126_cuSDR64src.tar.gz comes with .o files in bld/o which are compiled x86_64 files, "make clean" will get rid of them, then do "make -j 4". Be aware that different distros, Fedora, openSUSE, Ubuntu etc. use different package names so you must refine your search terms. Typically all distros provide most stuff so no need to build core applications, libraries or utilities. Unless you need a library at a higher level than the distro provides, avoid building and installing what is already provided. You can create deep pits to fall into later, sometimes much later if you are not careful. Ubuntu -- apt-cache search fftw. Fedora -- yum search fftw. openSUSE -- zypper se fftw Don't be tempted to enter package names as they may appear in another distro. When in doubt shorten the search string, e.g There are no packages with fftw3 in the name in Fedora while there are many in openSUSE and Ubuntu but again the package names differ. # yum search fftw3 Loaded plugins: langpacks, refresh-packagekit Warning: No matches found for: fftw3 No matches found These are the fft libraries installed in Fedora 20. # rpm -qa|grep fft fftw-libs-quad-3.3.4-3.fc20.x86_64 fftw-libs-single-3.3.4-3.fc20.x86_64 fftw-3.3.4-3.fc20.x86_64 fftw-libs-3.3.4-3.fc20.x86_64 fftw-libs-double-3.3.4-3.fc20.x86_64 fftw-devel-3.3.4-3.fc20.x86_64 fftw-libs-long-3.3.4-3.fc20.x86_64 Building Qt5, recommend using the instructions for ghpsdr3-alex which work on any platform. The instructions on the wiki for building ghpsdr3-alex avoid the use of symlinks, e.g if qt5 is built in /home/fred - "export PATH=/home/fred/qt5/qtbase/bin:$PATH" sets it up to use qt5. # qmake -v QMake version 3.0 Using Qt version 5.3.1 in /home/fred/qt5/qtbase/lib 73 ... Sid. On 17/08/14 17:37, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. > > One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- 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 From chris at vspl.co.uk Sun Aug 17 20:47:21 2014 From: chris at vspl.co.uk (Chris Smith) Date: Mon, 18 Aug 2014 04:47:21 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <53F128C1.7040900@blueyonder.co.uk> References: <20140817163704.A6AAD48278@diego.dreamhost.com> <53F128C1.7040900@blueyonder.co.uk> Message-ID: <20140818035052.63DBD48319@diego.dreamhost.com> Hi Sid As I mentioned off list I'm not a fan of Debian based distros because I find apt so difficult to use compared to yum. But by widening my search pattern in apt-cache search I was able to find libfftw3, so I've removed the version I built from sources and installed the package. cuSDR builds OK so I'm happy with that. Regarding Qt5, I would normally add to PATH but wanted a quick and dirty fix so changing the symlink was favourite. :-) 73, Chris G4NUX Sent from my iPad > On 17 Aug 2014, at 23:12, Sid Boyce wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Chris, > As mentioned - The first impression is that the TK1 is 64-bit, but it is quad-core 32-bit. It's still a powerful beast, CUDA ensures that. > > The next version apparently due later this year is dual-core 64-bit. > > 20140126_cuSDR64src.tar.gz comes with .o files in bld/o which are compiled x86_64 files, "make clean" will get rid of them, then do "make -j 4". > > Be aware that different distros, Fedora, openSUSE, Ubuntu etc. use different package names so you must refine your search terms. > Typically all distros provide most stuff so no need to build core applications, libraries or utilities. > Unless you need a library at a higher level than the distro provides, avoid building and installing what is already provided. You can create deep pits to fall into later, sometimes much later if you are not careful. > > Ubuntu -- apt-cache search fftw. > Fedora -- yum search fftw. > openSUSE -- zypper se fftw > > Don't be tempted to enter package names as they may appear in another distro. When in doubt shorten the search string, e.g There are no packages with fftw3 in the name in Fedora while there are many in openSUSE and Ubuntu but again the package names differ. > # yum search fftw3 > Loaded plugins: langpacks, refresh-packagekit > Warning: No matches found for: fftw3 > No matches found > > These are the fft libraries installed in Fedora 20. > # rpm -qa|grep fft > fftw-libs-quad-3.3.4-3.fc20.x86_64 > fftw-libs-single-3.3.4-3.fc20.x86_64 > fftw-3.3.4-3.fc20.x86_64 > fftw-libs-3.3.4-3.fc20.x86_64 > fftw-libs-double-3.3.4-3.fc20.x86_64 > fftw-devel-3.3.4-3.fc20.x86_64 > fftw-libs-long-3.3.4-3.fc20.x86_64 > > Building Qt5, recommend using the instructions for ghpsdr3-alex which work on any platform. > The instructions on the wiki for building ghpsdr3-alex avoid the use of symlinks, e.g if qt5 is built in /home/fred - "export PATH=/home/fred/qt5/qtbase/bin:$PATH" sets it up to use qt5. > # qmake -v > QMake version 3.0 > Using Qt version 5.3.1 in /home/fred/qt5/qtbase/lib > 73 ... Sid. > >> On 17/08/14 17:37, Chris Smith wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi >> >> Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. >> >> Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? >> >> Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. >> >> I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. >> >> Eventually cuSDR64 built and I could run it on the TK1 >> >> It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. >> >> The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. >> >> One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? >> >> Exciting to be able to use my TK1 in anger. >> >> Cheers & 73 >> >> Chris G4NUX >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > -- > 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 > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From g3vbv at blueyonder.co.uk Mon Aug 18 03:30:39 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 18 Aug 2014 11:30:39 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <53f1781b.ef21700a.2a89.ffff8ac3SMTPIN_ADDED_MISSING@mx.google.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> <53F128C1.7040900@blueyonder.co.uk> <53f1781b.ef21700a.2a89.ffff8ac3SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <53F1D5CF.4010805@blueyonder.co.uk> Hi Chris, I use whatever is before me, I have had to do that for decades working with 12 or more different OS's - yum search, zypper search/se, apt-*, aptitude search, pacman -S, not much of a difference between them really. I also stash tons of executable scripts that lighten the key pounding load. I have them in /usr/local/mybin which is permanently added to PATH. lancelot at slipstream:~> cat /usr/local/mybin/BUILD_GNURADIO #!/bin/sh cmake -DPYTHON_EXECUTABLE=/usr/bin/python2.7 -DPYTHON_INCLUDE_DIR=/usr/include/python2.7 -DPYTHON_LIBRARY=/usr/lib64/libpython2.7.so -DCMAKE_INSTALL_PREFIX=/usr . lancelot at slipstream:~> cat /usr/local/mybin/QUARTUS #!/bin/sh cd /home/lancelot/altera/13.0/quartus/bin/ ./quartus& lancelot at slipstream:~> cat /usr/local/mybin/HERMES_384K #!/bin/sh hpsdr-server --hermes 255 --samplerate 384000 --interface enp3s0 & There is only one OS I have ever shied away from as I was never required to use it to earn a daily crust. The one with the fur coat and no under garments. 73 ... Sid. On 18/08/14 04:47, Chris Smith wrote: > Hi Sid > > As I mentioned off list I'm not a fan of Debian based distros because I find apt so difficult to use compared to yum. But by widening my search pattern in apt-cache search I was able to find libfftw3, so I've removed the version I built from sources and installed the package. cuSDR builds OK so I'm happy with that. > > Regarding Qt5, I would normally add to PATH but wanted a quick and dirty fix so changing the symlink was favourite. :-) > > 73, Chris G4NUX > > Sent from my iPad > >> On 17 Aug 2014, at 23:12, Sid Boyce wrote: >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Chris, >> As mentioned - The first impression is that the TK1 is 64-bit, but it is quad-core 32-bit. It's still a powerful beast, CUDA ensures that. >> >> The next version apparently due later this year is dual-core 64-bit. >> >> 20140126_cuSDR64src.tar.gz comes with .o files in bld/o which are compiled x86_64 files, "make clean" will get rid of them, then do "make -j 4". >> >> Be aware that different distros, Fedora, openSUSE, Ubuntu etc. use different package names so you must refine your search terms. >> Typically all distros provide most stuff so no need to build core applications, libraries or utilities. >> Unless you need a library at a higher level than the distro provides, avoid building and installing what is already provided. You can create deep pits to fall into later, sometimes much later if you are not careful. >> >> Ubuntu -- apt-cache search fftw. >> Fedora -- yum search fftw. >> openSUSE -- zypper se fftw >> >> Don't be tempted to enter package names as they may appear in another distro. When in doubt shorten the search string, e.g There are no packages with fftw3 in the name in Fedora while there are many in openSUSE and Ubuntu but again the package names differ. >> # yum search fftw3 >> Loaded plugins: langpacks, refresh-packagekit >> Warning: No matches found for: fftw3 >> No matches found >> >> These are the fft libraries installed in Fedora 20. >> # rpm -qa|grep fft >> fftw-libs-quad-3.3.4-3.fc20.x86_64 >> fftw-libs-single-3.3.4-3.fc20.x86_64 >> fftw-3.3.4-3.fc20.x86_64 >> fftw-libs-3.3.4-3.fc20.x86_64 >> fftw-libs-double-3.3.4-3.fc20.x86_64 >> fftw-devel-3.3.4-3.fc20.x86_64 >> fftw-libs-long-3.3.4-3.fc20.x86_64 >> >> Building Qt5, recommend using the instructions for ghpsdr3-alex which work on any platform. >> The instructions on the wiki for building ghpsdr3-alex avoid the use of symlinks, e.g if qt5 is built in /home/fred - "export PATH=/home/fred/qt5/qtbase/bin:$PATH" sets it up to use qt5. >> # qmake -v >> QMake version 3.0 >> Using Qt version 5.3.1 in /home/fred/qt5/qtbase/lib >> 73 ... Sid. >> >>> On 17/08/14 17:37, Chris Smith wrote: >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> Hi >>> >>> Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. >>> >>> Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? >>> >>> Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. >>> >>> I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. >>> >>> Eventually cuSDR64 built and I could run it on the TK1 >>> >>> It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. >>> >>> The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. >>> >>> One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? >>> >>> Exciting to be able to use my TK1 in anger. >>> >>> Cheers & 73 >>> >>> Chris G4NUX >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> -- >> 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 >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 From hvh.net at gmail.com Mon Aug 18 04:24:23 2014 From: hvh.net at gmail.com (Hermann) Date: Mon, 18 Aug 2014 13:24:23 +0200 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <20140817163704.A6AAD48278@diego.dreamhost.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: Dear Chris, congratulations! What I noticed last year when I did some experiments with cuSDR on my Gentoo box is also a higher CPU load compared to a Windows box. I did not took a closer look at yet where this might come from, but it could depend on many things. I will compile cuSDR on my Jetson in short (I hope so, hi) and will take a closer look at. Maybe the strategy of advising/generating threads in cuSDR has to be modified to suit the Linux scheduler, but this is purely speculative for now. 73, Hermann DL3HVH On Sun, Aug 17, 2014 at 6:37 PM, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my recently > acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for some > years now, building the libraries from sources under Fedora Linux & OSX. I > found the published build instructions using git a bit longwinded but > eventually succeeded. Does anyone know what the -j4 option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after > changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version > in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring > the Makefile up to date. I didn't do a make clean so some .o files reported > "wrong file type" but removing the 3 offending .o files led me to the next > problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 > https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz > ) and apart from configure requiring a couple of qualifiers ( ./configure > --enable-single --enable-shared ) that library built and installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run cuSDR > on any platform before) but everything appeared to be working. My Atlas > hardware was correctly reported along with ancient f/w versions and I could > hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a > roller wheel in the shack so the only way I seem to be able to tune is to > drag the frequency bar under the display left-right. That is far too crude > to tune an individual QSO but got me some audio recognisable as a contact. > > One thing which alarms me slightly is that the CPU usage reported is in > the range 152-175% I assume that is reporting that more than one core > (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at vspl.co.uk Mon Aug 18 06:32:16 2014 From: chris at vspl.co.uk (Chris Smith) Date: Mon, 18 Aug 2014 14:32:16 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <20140818133219.75557481E0@diego.dreamhost.com> Hi Herman I'm so encouraged by the success of this venture that I'm going to build cuSDR64 on my HPSDR dual-boot system - WinXP/F19. I'd like to be shot of Windows for good. PowerSDR is the only piece of software that I currently use that needs Windows. I'll let you know how I get on there. 73, Chris G4NUX On 18 Aug 2014, at 12:24, Hermann wrote: > Dear Chris, > > congratulations! What I noticed last year when I did some experiments with cuSDR on my Gentoo box is also a higher CPU load compared to a Windows box. I did not took a closer look at yet where this might come from, but it could depend on many things. I will compile cuSDR on my Jetson in short (I hope so, hi) and will take a closer look at. Maybe the strategy of advising/generating threads in cuSDR has to be modified to suit the Linux scheduler, but this is purely speculative for now. > > > 73, Hermann DL3HVH > > > On Sun, Aug 17, 2014 at 6:37 PM, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. > > One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From irbsurfing at yahoo.co.uk Tue Aug 19 13:04:06 2014 From: irbsurfing at yahoo.co.uk (Andrew) Date: Tue, 19 Aug 2014 21:04:06 +0100 Subject: [hpsdr] Wideband waterfall display Message-ID: <1408478646.90961.YahooMailNeo@web171206.mail.ir2.yahoo.com> Hi, Just wondering if anyone knows of a piece of software that can show a 0-55MHz wideband waterfall display with Hermes etc? I know Kiss Konsole and CuSDR have a wideband pan-adapter, but not a waterfall as far as I know. Thanks, Andrew G4XZL -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvh.net at gmail.com Tue Aug 19 13:09:40 2014 From: hvh.net at gmail.com (Hermann) Date: Tue, 19 Aug 2014 22:09:40 +0200 Subject: [hpsdr] Wideband waterfall display In-Reply-To: <1408478646.90961.YahooMailNeo@web171206.mail.ir2.yahoo.com> References: <1408478646.90961.YahooMailNeo@web171206.mail.ir2.yahoo.com> Message-ID: Hi Andrew, Next version of cuSDR has a wideband waterfall display. In the beta this is already working. 73, Hermann DL3HVH Sent from my Nexus 5 On Aug 19, 2014 10:04 PM, "Andrew" wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > Hi, > Just wondering if anyone knows of a piece of software that can show a > 0-55MHz wideband waterfall display with Hermes etc? > I know Kiss Konsole and CuSDR have a wideband pan-adapter, but not a > waterfall as far as I know. > Thanks, > Andrew > G4XZL > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at pharman.org Wed Aug 20 00:31:26 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 15:31:26 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. In order to open the SDR world to those with PC software skills we are in the process of developing a new SDR architecture. This architecture digitises the entire 0 to 30MHz radio spectrum in real time and passes the 'raw' samples directly to an associated computer. This computer then calculates the FFT of the raw samples and subsequently processes the result as the user requires. This is not a totally new concept since both the cuSDR and KISS Konsole software uses raw ADC samples to provide the wideband bandscope displays. However, for this requirement the FFT only needs to be done at the bandscope update rate of a few 10's of times per second, which hardly taxes a modern PC at all. The new concept requires that we take the FFT of all samples in real-time. This has been possible in the past - if you had access to a Cray super computer! Well now we do have access to very low cost computers that provide the processing power we need. One example of this is the new Nvidia Jetson TK1 single board computer. At a cost of $192 this board contains four ARM CPUs plus 192 CUDA processors. More details of this remarkable board can be found here: https://developer.nvidia.com/jetson-tk1 Since the CUDA cores can process data in parallel, we can use these to perform the high speed FFT. John, G0ORX, has written preliminary code for the Jetson board and has confirmed that it has the necessary performance we require. The test environment consisted of a Jetson board connected via Gigabit Ethernet to an Angelia board. A special version of FPGA code was written for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the Jetson board. We used raw Ethernet frames over the Gigabit link, in order to maximise the link bandwidth, since we require a sustained 983Mbps transfer rate. Whilst it's still early days, and there is much more to be done, this critical early success does indicate that this new architecture has a very promising future. The Jetson board is taking the role of an 'SDR Server' which I have written about in the past. In which case what benefits does this new architecture provide to openHPSR? 1. The FPGA code is greatly simplified, is easier to write and maintain, and hence uses a small percentage of the space available with a subsequent reduction in power consumption. 2. The protocol between the SDR hardware and the SDR Server is greatly simplified since the SDR hardware only has to connect to a single, dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer required. The SDR Server simply needs to know the MAC address of the SDR hardware in order to communicate. It should be possible for a single SDR hardware board to feed multiple SDR Servers, but that's something for the future. 3. Virtually all the signal processing is undertaken on the associated single board computer (SBC) or (suitable) PC. If sufficient processing power is available then the GUI can run on the same SBC. Alternatively the user's normal PC (which does not require to be high performance since it does not do any significant digital signal processing) or a Tablet, cell phone etc could be used. 4. Many more users have the necessary skills and experience to support, maintain and further develop the code. New features are added to the SDR Server code rather than the FPGA code. 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA and/or power supply restrictions may have limited adding new features. 6. Future hardware upgrades will be to the associated SBC where faster and lower cost options can be expected. Nvidia have already indicated that a 64 bit board will be available in the near future. 7. Remote access to an SDR via the Internet will enable multiple users to share the SDR with each selecting their desired frequency, bandwidth and mode. There are other potential benefits relating to simpler and lower cost SDR hardware, but that is for the future. For want of a name we are calling this new architecture 'Direct Fourier Conversion' (DFC). For those that are already experimenting with the Jetson board we do intend to release the DFC FPGA code for both Angelia and Hermes boards and I will advise when, and where, this is available. John's code is presently not available, so please don't pester him, but as soon as it reaches Beta stage it will be released. Please join me in congratulating John on this exciting development. 73 Phil....VK6PH From chris at vspl.co.uk Wed Aug 20 00:42:58 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 08:42:58 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <20140820074302.6AB7048864@diego.dreamhost.com> Hi Phil I had a feeling, when I saw your paper and Hermann's at Friedrischafen, that DFC was the way things were going. Which is why I jumped on the TK1 bandwagon. Will there ever be a way of using the Mercury front end to supply the raw packets, perhaps with a bespoke daughter board? Congrats to John whom I had the pleasure of speaking to at Friedrischafen. I'm sure we all look forward to the new era of SDR in the amateur radio arena. Cheers & 73 Chris G4NUX On 20 Aug 2014, at 08:31, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From roland.etienne at free.fr Wed Aug 20 00:48:52 2014 From: roland.etienne at free.fr (Roland Etienne) Date: Wed, 20 Aug 2014 09:48:52 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <0EDA19C686524970B4E75CD8483127AE@F8CHKAtom> Hi Phil, Very exciting news! Congrats to John and all of you, crazy programmers! how do you find the time to do all that job ?? Thanks a lot for the fun you're giving us! 73, Roland F8CHK > -----Message d'origine----- > De?: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] De la part de Phil > Harman > Envoy??: mercredi 20 ao?t 2014 09:31 > ??: hpsdr at lists.openhpsdr.org > Objet?: [hpsdr] openHPSDR at the forefront of SDR development > > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > .... > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > .... > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr- > openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From phil at pharman.org Wed Aug 20 01:22:48 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 16:22:48 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: Hi Chris, The limitation of using the Mercury board together with Metis is the bandwidth of the Alex bus. If would could couple the two boards together in a suitable way then we can use the existing Mercury board. 73 Phil...VK6PH > Hi Phil > > I had a feeling, when I saw your paper and Hermann's at Friedrischafen, > that DFC was the way things were going. Which is why I jumped on the TK1 > bandwagon. > > Will there ever be a way of using the Mercury front end to supply the raw > packets, perhaps with a bespoke daughter board? > > Congrats to John whom I had the pleasure of speaking to at Friedrischafen. > I'm sure we all look forward to the new era of SDR in the amateur radio > arena. > > Cheers & 73 > > Chris G4NUX > > On 20 Aug 2014, at 08:31, Phil Harman wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> I'm delighted to be able to report that we have been able to develop, to >> proof-of-concept stage, a new SDR architecture. >> >> Current SDRs use the software equivalent of zero IF techniques, i.e. >> DDC, >> in order to provide (multiple) receivers. Whist this is quite >> effective, >> much of the initial DSP work is done using FPGAs, or a combination of >> FPGA >> plus dedicated DSP chips and microprocessors, rather than totally within >> the PC. >> >> As more complex features are added, the size and complexity of the FPGA >> and DSP code increases. The skills to write, debug and maintain this >> code >> is only available via a small percentage of software engineers, or >> enthusiasts, in comparison to those able to write code for PC based >> hardware. >> >> In order to open the SDR world to those with PC software skills we are >> in >> the process of developing a new SDR architecture. >> >> This architecture digitises the entire 0 to 30MHz radio spectrum in real >> time and passes the 'raw' samples directly to an associated computer. >> >> This computer then calculates the FFT of the raw samples and >> subsequently >> processes the result as the user requires. >> >> This is not a totally new concept since both the cuSDR and KISS Konsole >> software uses raw ADC samples to provide the wideband bandscope >> displays. >> >> However, for this requirement the FFT only needs to be done at the >> bandscope update rate of a few 10's of times per second, which hardly >> taxes a modern PC at all. >> >> The new concept requires that we take the FFT of all samples in >> real-time. >> >> This has been possible in the past - if you had access to a Cray super >> computer! >> >> Well now we do have access to very low cost computers that provide the >> processing power we need. One example of this is the new Nvidia Jetson >> TK1 single board computer. At a cost of $192 this board contains four >> ARM >> CPUs plus 192 CUDA processors. >> >> More details of this remarkable board can be found here: >> >> https://developer.nvidia.com/jetson-tk1 >> >> Since the CUDA cores can process data in parallel, we can use these to >> perform the high speed FFT. >> >> John, G0ORX, has written preliminary code for the Jetson board and has >> confirmed that it has the necessary performance we require. >> >> The test environment consisted of a Jetson board connected via Gigabit >> Ethernet to an Angelia board. A special version of FPGA code was >> written >> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >> the >> Jetson board. >> >> We used raw Ethernet frames over the Gigabit link, in order to maximise >> the link bandwidth, since we require a sustained 983Mbps transfer rate. >> >> Whilst it's still early days, and there is much more to be done, this >> critical early success does indicate that this new architecture has a >> very >> promising future. >> >> The Jetson board is taking the role of an 'SDR Server' which I have >> written about in the past. >> >> In which case what benefits does this new architecture provide to >> openHPSR? >> >> 1. The FPGA code is greatly simplified, is easier to write and maintain, >> and hence uses a small percentage of the space available with a >> subsequent >> reduction in power consumption. >> >> 2. The protocol between the SDR hardware and the SDR Server is greatly >> simplified since the SDR hardware only has to connect to a single, >> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >> required. The SDR Server simply needs to know the MAC address of the >> SDR >> hardware in order to communicate. It should be possible for a single >> SDR >> hardware board to feed multiple SDR Servers, but that's something for >> the >> future. >> >> 3. Virtually all the signal processing is undertaken on the associated >> single board computer (SBC) or (suitable) PC. If sufficient processing >> power is available then the GUI can run on the same SBC. Alternatively >> the >> user's normal PC (which does not require to be high performance since it >> does not do any significant digital signal processing) or a Tablet, cell >> phone etc could be used. >> >> 4. Many more users have the necessary skills and experience to support, >> maintain and further develop the code. New features are added to the SDR >> Server code rather than the FPGA code. >> >> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >> FPGA >> and/or power supply restrictions may have limited adding new features. >> >> 6. Future hardware upgrades will be to the associated SBC where faster >> and >> lower cost options can be expected. Nvidia have already indicated that >> a >> 64 bit board will be available in the near future. >> >> 7. Remote access to an SDR via the Internet will enable multiple users >> to >> share the SDR with each selecting their desired frequency, bandwidth and >> mode. >> >> There are other potential benefits relating to simpler and lower cost >> SDR >> hardware, but that is for the future. >> >> For want of a name we are calling this new architecture 'Direct Fourier >> Conversion' (DFC). >> >> For those that are already experimenting with the Jetson board we do >> intend to release the DFC FPGA code for both Angelia and Hermes boards >> and >> I will advise when, and where, this is available. >> >> John's code is presently not available, so please don't pester him, but >> as >> soon as it reaches Beta stage it will be released. >> >> Please join me in congratulating John on this exciting development. >> >> 73 Phil....VK6PH >> >> >> >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > From dc6ny at gmx.de Wed Aug 20 01:48:31 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Wed, 20 Aug 2014 10:48:31 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <000001cfbc53$85bf7be0$913e73a0$@de> Hi Phil, Congratulations. Maybe a stupid question: Current bottleneck is the 1 Gbit/s LAN connection that makes a decimation by factor 2 necessary or limits the frequency range to 33MHz, i.e. we lose 6m band at least as raw I/Q. Is there no (economic) way to get the LAN connection faster? 14 and 16 Bit ADC/DACs are getting faster and low-jitter sampling oscillators up to 300MHz are available, hence a lot of nice applications are imaginable, hi. 73, Helmut, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von Phil Harman Gesendet: Mittwoch, 20. August 2014 09:31 An: hpsdr at lists.openhpsdr.org Betreff: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. In order to open the SDR world to those with PC software skills we are in the process of developing a new SDR architecture. This architecture digitises the entire 0 to 30MHz radio spectrum in real time and passes the 'raw' samples directly to an associated computer. This computer then calculates the FFT of the raw samples and subsequently processes the result as the user requires. This is not a totally new concept since both the cuSDR and KISS Konsole software uses raw ADC samples to provide the wideband bandscope displays. However, for this requirement the FFT only needs to be done at the bandscope update rate of a few 10's of times per second, which hardly taxes a modern PC at all. The new concept requires that we take the FFT of all samples in real-time. This has been possible in the past - if you had access to a Cray super computer! Well now we do have access to very low cost computers that provide the processing power we need. One example of this is the new Nvidia Jetson TK1 single board computer. At a cost of $192 this board contains four ARM CPUs plus 192 CUDA processors. More details of this remarkable board can be found here: https://developer.nvidia.com/jetson-tk1 Since the CUDA cores can process data in parallel, we can use these to perform the high speed FFT. John, G0ORX, has written preliminary code for the Jetson board and has confirmed that it has the necessary performance we require. The test environment consisted of a Jetson board connected via Gigabit Ethernet to an Angelia board. A special version of FPGA code was written for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the Jetson board. We used raw Ethernet frames over the Gigabit link, in order to maximise the link bandwidth, since we require a sustained 983Mbps transfer rate. Whilst it's still early days, and there is much more to be done, this critical early success does indicate that this new architecture has a very promising future. The Jetson board is taking the role of an 'SDR Server' which I have written about in the past. In which case what benefits does this new architecture provide to openHPSR? 1. The FPGA code is greatly simplified, is easier to write and maintain, and hence uses a small percentage of the space available with a subsequent reduction in power consumption. 2. The protocol between the SDR hardware and the SDR Server is greatly simplified since the SDR hardware only has to connect to a single, dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer required. The SDR Server simply needs to know the MAC address of the SDR hardware in order to communicate. It should be possible for a single SDR hardware board to feed multiple SDR Servers, but that's something for the future. 3. Virtually all the signal processing is undertaken on the associated single board computer (SBC) or (suitable) PC. If sufficient processing power is available then the GUI can run on the same SBC. Alternatively the user's normal PC (which does not require to be high performance since it does not do any significant digital signal processing) or a Tablet, cell phone etc could be used. 4. Many more users have the necessary skills and experience to support, maintain and further develop the code. New features are added to the SDR Server code rather than the FPGA code. 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA and/or power supply restrictions may have limited adding new features. 6. Future hardware upgrades will be to the associated SBC where faster and lower cost options can be expected. Nvidia have already indicated that a 64 bit board will be available in the near future. 7. Remote access to an SDR via the Internet will enable multiple users to share the SDR with each selecting their desired frequency, bandwidth and mode. There are other potential benefits relating to simpler and lower cost SDR hardware, but that is for the future. For want of a name we are calling this new architecture 'Direct Fourier Conversion' (DFC). For those that are already experimenting with the Jetson board we do intend to release the DFC FPGA code for both Angelia and Hermes boards and I will advise when, and where, this is available. John's code is presently not available, so please don't pester him, but as soon as it reaches Beta stage it will be released. Please join me in congratulating John on this exciting development. 73 Phil....VK6PH _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From chris at vspl.co.uk Wed Aug 20 01:48:56 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 09:48:56 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <20140820084900.495FC4861E@diego.dreamhost.com> Hi Phil I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) Cheers Chris On 20 Aug 2014, at 09:22, "Phil Harman" wrote: > Hi Chris, > > The limitation of using the Mercury board together with Metis is the > bandwidth of the Alex bus. > > If would could couple the two boards together in a suitable way then we > can use the existing Mercury board. > > 73 Phil...VK6PH > > >> Hi Phil >> >> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >> that DFC was the way things were going. Which is why I jumped on the TK1 >> bandwagon. >> >> Will there ever be a way of using the Mercury front end to supply the raw >> packets, perhaps with a bespoke daughter board? >> >> Congrats to John whom I had the pleasure of speaking to at Friedrischafen. >> I'm sure we all look forward to the new era of SDR in the amateur radio >> arena. >> >> Cheers & 73 >> >> Chris G4NUX >> >> On 20 Aug 2014, at 08:31, Phil Harman wrote: >> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> All, >>> >>> I'm delighted to be able to report that we have been able to develop, to >>> proof-of-concept stage, a new SDR architecture. >>> >>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>> DDC, >>> in order to provide (multiple) receivers. Whist this is quite >>> effective, >>> much of the initial DSP work is done using FPGAs, or a combination of >>> FPGA >>> plus dedicated DSP chips and microprocessors, rather than totally within >>> the PC. >>> >>> As more complex features are added, the size and complexity of the FPGA >>> and DSP code increases. The skills to write, debug and maintain this >>> code >>> is only available via a small percentage of software engineers, or >>> enthusiasts, in comparison to those able to write code for PC based >>> hardware. >>> >>> In order to open the SDR world to those with PC software skills we are >>> in >>> the process of developing a new SDR architecture. >>> >>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>> time and passes the 'raw' samples directly to an associated computer. >>> >>> This computer then calculates the FFT of the raw samples and >>> subsequently >>> processes the result as the user requires. >>> >>> This is not a totally new concept since both the cuSDR and KISS Konsole >>> software uses raw ADC samples to provide the wideband bandscope >>> displays. >>> >>> However, for this requirement the FFT only needs to be done at the >>> bandscope update rate of a few 10's of times per second, which hardly >>> taxes a modern PC at all. >>> >>> The new concept requires that we take the FFT of all samples in >>> real-time. >>> >>> This has been possible in the past - if you had access to a Cray super >>> computer! >>> >>> Well now we do have access to very low cost computers that provide the >>> processing power we need. One example of this is the new Nvidia Jetson >>> TK1 single board computer. At a cost of $192 this board contains four >>> ARM >>> CPUs plus 192 CUDA processors. >>> >>> More details of this remarkable board can be found here: >>> >>> https://developer.nvidia.com/jetson-tk1 >>> >>> Since the CUDA cores can process data in parallel, we can use these to >>> perform the high speed FFT. >>> >>> John, G0ORX, has written preliminary code for the Jetson board and has >>> confirmed that it has the necessary performance we require. >>> >>> The test environment consisted of a Jetson board connected via Gigabit >>> Ethernet to an Angelia board. A special version of FPGA code was >>> written >>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>> the >>> Jetson board. >>> >>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>> >>> Whilst it's still early days, and there is much more to be done, this >>> critical early success does indicate that this new architecture has a >>> very >>> promising future. >>> >>> The Jetson board is taking the role of an 'SDR Server' which I have >>> written about in the past. >>> >>> In which case what benefits does this new architecture provide to >>> openHPSR? >>> >>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>> and hence uses a small percentage of the space available with a >>> subsequent >>> reduction in power consumption. >>> >>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>> simplified since the SDR hardware only has to connect to a single, >>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>> required. The SDR Server simply needs to know the MAC address of the >>> SDR >>> hardware in order to communicate. It should be possible for a single >>> SDR >>> hardware board to feed multiple SDR Servers, but that's something for >>> the >>> future. >>> >>> 3. Virtually all the signal processing is undertaken on the associated >>> single board computer (SBC) or (suitable) PC. If sufficient processing >>> power is available then the GUI can run on the same SBC. Alternatively >>> the >>> user's normal PC (which does not require to be high performance since it >>> does not do any significant digital signal processing) or a Tablet, cell >>> phone etc could be used. >>> >>> 4. Many more users have the necessary skills and experience to support, >>> maintain and further develop the code. New features are added to the SDR >>> Server code rather than the FPGA code. >>> >>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>> FPGA >>> and/or power supply restrictions may have limited adding new features. >>> >>> 6. Future hardware upgrades will be to the associated SBC where faster >>> and >>> lower cost options can be expected. Nvidia have already indicated that >>> a >>> 64 bit board will be available in the near future. >>> >>> 7. Remote access to an SDR via the Internet will enable multiple users >>> to >>> share the SDR with each selecting their desired frequency, bandwidth and >>> mode. >>> >>> There are other potential benefits relating to simpler and lower cost >>> SDR >>> hardware, but that is for the future. >>> >>> For want of a name we are calling this new architecture 'Direct Fourier >>> Conversion' (DFC). >>> >>> For those that are already experimenting with the Jetson board we do >>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>> and >>> I will advise when, and where, this is available. >>> >>> John's code is presently not available, so please don't pester him, but >>> as >>> soon as it reaches Beta stage it will be released. >>> >>> Please join me in congratulating John on this exciting development. >>> >>> 73 Phil....VK6PH >>> >>> >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: >>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> >> > From meijer.ha at home.nl Wed Aug 20 01:58:26 2014 From: meijer.ha at home.nl (H.A.Meijer) Date: Wed, 20 Aug 2014 10:58:26 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F46332.9040601@home.nl> Phil Harman schreef op 20-8-2014 om 9:31: > ***** High Performance Software Defined Radio Discussion List ***** > > > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > Hi, I'm just a "end-user" and not a software engineer, so it's not very easy, for me, to understand all of this. Does it mean that that this "new board" is connected between your sdr transceiver (hermes etc) and your PC?. I would rater like a 'stand-alone' and 'High Performance' solution for better DSP functionality etc, and to get rid of my pc, then an extra board that just needs more soft- and firmware.... But I understand that this is very exiting for software engineers, so good luck. Bert PA2XHF --- Dit e-mailbericht bevat geen virussen en malware omdat avast! Antivirus-bescherming actief is. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dc6ny at gmx.de Wed Aug 20 02:09:52 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Wed, 20 Aug 2014 11:09:52 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F46332.9040601@home.nl> References: <53F46332.9040601@home.nl> Message-ID: <000c01cfbc56$808c9560$81a5c020$@de> Hi Bert, please see Phil's presentation 'Further prospective of HPSDR' at http://openhpsdr.org/publications.php and you will collect a lot of important info. 73, Helmut, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von H.A.Meijer Gesendet: Mittwoch, 20. August 2014 10:58 An: hpsdr at lists.openhpsdr.org Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** From ksyverud at broadpark.no Wed Aug 20 02:51:45 2014 From: ksyverud at broadpark.no (Kjell Syverud) Date: Wed, 20 Aug 2014 11:51:45 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F46FB1.2050304@broadpark.no> Hi Phil. Nice to hear you can confirm the "DFC" as you presented it in Friedrichshafen. One question, may be you commented it in Friedrichshafen, but i can not remember: Will it be possible to cover 30 to 60 MHz ? 73 LA9CY/Kjell From phil at pharman.org Wed Aug 20 04:15:36 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 19:15:36 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F46332.9040601@home.nl> References: <53F46332.9040601@home.nl> Message-ID: <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> Hi Bert, Yes, as we are today the ?new board? is connected between your SDR hardware and your PC. It may be possible to run both the SDR server and Client GUI software on the one SBC or PC. Its a little early yet to know if the Jetson board is capable of doing this. If so, then with your SDR hardware you would have a dedicated SDR that does not require an additional PC. This could all be packaged into a case with a suitable touch screen etc. You can always do that today by using a suitable SBC that will run Windows. 73 Phil...VK6PH Hi, I'm just a "end-user" and not a software engineer, so it's not very easy, for me, to understand all of this. Does it mean that that this "new board" is connected between your sdr transceiver (hermes etc) and your PC?. I would rater like a 'stand-alone' and 'High Performance' solution for better DSP functionality etc, and to get rid of my pc, then an extra board that just needs more soft- and firmware.... But I understand that this is very exiting for software engineers, so good luck. Bert PA2XHF -------------------------------------------------------------------------------- Dit e-mailbericht bevat geen virussen en malware omdat avast! Antivirus actief is. -------------------------------------------------------------------------------- _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at pharman.org Wed Aug 20 04:28:08 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 19:28:08 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F46FB1.2050304@broadpark.no> References: <53F46FB1.2050304@broadpark.no> Message-ID: <0EB6587E8CAE411C8E61A6B0215E7070@ShackPC2> Hi Kjell, Initially its not going to be possible to cover 0 to 55MHz of spectrum since with 16 bits of ADC data that would exceed the capacity of the Gigabit channel. We could reduce the ADC data to 8 bits but that would hardly meet the 'High Performance' requirement! We can still use 6m since this will alias into the 0-30MHz range, but we can't do both at the same time. We still have 16Mbps 'spare' in the Ethernet bandwidth so we may be able to include 6m using a conventional DDC. Still early days, we can use the mini PCIe interface on the Jetson board to interface to the ADC/DAC in order to run at faster sampling rates. At the moment we don't know how much spare processing capacity we have on board so still lots more tests to run. 73 Phil...VK6PH -----Original Message----- From: Kjell Syverud Sent: Wednesday, August 20, 2014 5:51 PM To: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Hi Phil. Nice to hear you can confirm the "DFC" as you presented it in Friedrichshafen. One question, may be you commented it in Friedrichshafen, but i can not remember: Will it be possible to cover 30 to 60 MHz ? 73 LA9CY/Kjell _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From phil at pharman.org Wed Aug 20 04:37:31 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 19:37:31 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> Hi Chris. Alternatively, you could make a small PCB that plugged into J5 on Mercury that held the PHY, 25MHz clock and Ethernet socket. Since you no longer need any DDC code in the FPGA you would have plenty of room to house the raw Ethernet code. 'Weekend Project' anyone ? 73 Phil....VK6PH -----Original Message----- From: Chris Smith Sent: Wednesday, August 20, 2014 4:48 PM To: phil at pharman.org Cc: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development Hi Phil I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) Cheers Chris On 20 Aug 2014, at 09:22, "Phil Harman" wrote: > Hi Chris, > > The limitation of using the Mercury board together with Metis is the > bandwidth of the Alex bus. > > If would could couple the two boards together in a suitable way then we > can use the existing Mercury board. > > 73 Phil...VK6PH > > >> Hi Phil >> >> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >> that DFC was the way things were going. Which is why I jumped on the TK1 >> bandwagon. >> >> Will there ever be a way of using the Mercury front end to supply the raw >> packets, perhaps with a bespoke daughter board? >> >> Congrats to John whom I had the pleasure of speaking to at >> Friedrischafen. >> I'm sure we all look forward to the new era of SDR in the amateur radio >> arena. >> >> Cheers & 73 >> >> Chris G4NUX >> >> On 20 Aug 2014, at 08:31, Phil Harman wrote: >> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> All, >>> >>> I'm delighted to be able to report that we have been able to develop, to >>> proof-of-concept stage, a new SDR architecture. >>> >>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>> DDC, >>> in order to provide (multiple) receivers. Whist this is quite >>> effective, >>> much of the initial DSP work is done using FPGAs, or a combination of >>> FPGA >>> plus dedicated DSP chips and microprocessors, rather than totally within >>> the PC. >>> >>> As more complex features are added, the size and complexity of the FPGA >>> and DSP code increases. The skills to write, debug and maintain this >>> code >>> is only available via a small percentage of software engineers, or >>> enthusiasts, in comparison to those able to write code for PC based >>> hardware. >>> >>> In order to open the SDR world to those with PC software skills we are >>> in >>> the process of developing a new SDR architecture. >>> >>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>> time and passes the 'raw' samples directly to an associated computer. >>> >>> This computer then calculates the FFT of the raw samples and >>> subsequently >>> processes the result as the user requires. >>> >>> This is not a totally new concept since both the cuSDR and KISS Konsole >>> software uses raw ADC samples to provide the wideband bandscope >>> displays. >>> >>> However, for this requirement the FFT only needs to be done at the >>> bandscope update rate of a few 10's of times per second, which hardly >>> taxes a modern PC at all. >>> >>> The new concept requires that we take the FFT of all samples in >>> real-time. >>> >>> This has been possible in the past - if you had access to a Cray super >>> computer! >>> >>> Well now we do have access to very low cost computers that provide the >>> processing power we need. One example of this is the new Nvidia Jetson >>> TK1 single board computer. At a cost of $192 this board contains four >>> ARM >>> CPUs plus 192 CUDA processors. >>> >>> More details of this remarkable board can be found here: >>> >>> https://developer.nvidia.com/jetson-tk1 >>> >>> Since the CUDA cores can process data in parallel, we can use these to >>> perform the high speed FFT. >>> >>> John, G0ORX, has written preliminary code for the Jetson board and has >>> confirmed that it has the necessary performance we require. >>> >>> The test environment consisted of a Jetson board connected via Gigabit >>> Ethernet to an Angelia board. A special version of FPGA code was >>> written >>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>> the >>> Jetson board. >>> >>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>> >>> Whilst it's still early days, and there is much more to be done, this >>> critical early success does indicate that this new architecture has a >>> very >>> promising future. >>> >>> The Jetson board is taking the role of an 'SDR Server' which I have >>> written about in the past. >>> >>> In which case what benefits does this new architecture provide to >>> openHPSR? >>> >>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>> and hence uses a small percentage of the space available with a >>> subsequent >>> reduction in power consumption. >>> >>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>> simplified since the SDR hardware only has to connect to a single, >>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>> required. The SDR Server simply needs to know the MAC address of the >>> SDR >>> hardware in order to communicate. It should be possible for a single >>> SDR >>> hardware board to feed multiple SDR Servers, but that's something for >>> the >>> future. >>> >>> 3. Virtually all the signal processing is undertaken on the associated >>> single board computer (SBC) or (suitable) PC. If sufficient processing >>> power is available then the GUI can run on the same SBC. Alternatively >>> the >>> user's normal PC (which does not require to be high performance since it >>> does not do any significant digital signal processing) or a Tablet, cell >>> phone etc could be used. >>> >>> 4. Many more users have the necessary skills and experience to support, >>> maintain and further develop the code. New features are added to the SDR >>> Server code rather than the FPGA code. >>> >>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>> FPGA >>> and/or power supply restrictions may have limited adding new features. >>> >>> 6. Future hardware upgrades will be to the associated SBC where faster >>> and >>> lower cost options can be expected. Nvidia have already indicated that >>> a >>> 64 bit board will be available in the near future. >>> >>> 7. Remote access to an SDR via the Internet will enable multiple users >>> to >>> share the SDR with each selecting their desired frequency, bandwidth and >>> mode. >>> >>> There are other potential benefits relating to simpler and lower cost >>> SDR >>> hardware, but that is for the future. >>> >>> For want of a name we are calling this new architecture 'Direct Fourier >>> Conversion' (DFC). >>> >>> For those that are already experimenting with the Jetson board we do >>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>> and >>> I will advise when, and where, this is available. >>> >>> John's code is presently not available, so please don't pester him, but >>> as >>> soon as it reaches Beta stage it will be released. >>> >>> Please join me in congratulating John on this exciting development. >>> >>> 73 Phil....VK6PH >>> >>> >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: >>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> >> > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From jeffrie at talktalk.net Wed Aug 20 06:25:58 2014 From: jeffrie at talktalk.net (Jeff Cook) Date: Wed, 20 Aug 2014 14:25:58 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <000001cfbc7a$47ce2d00$d76a8700$@talktalk.net> Hello Phil, As the epitome of what is an end user, button pusher, knob twiddler, et cetera, I readily admit to understanding little of which you speak, but your enthusiasm is infectious and your excitement palpable. I am still back in the days of Mercury and Ozymandias and love every minute of it, so thank you to you, and John, and all the others that are the true exponents of the radio art. It really is a pleasure being on board this particular magic of radio train, even though I have no idea where it's going. Jeff, G0AFQ. -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vrf at johnc57uk.plus.com Wed Aug 20 06:54:16 2014 From: g3vrf at johnc57uk.plus.com (G3VRF) Date: Wed, 20 Aug 2014 14:54:16 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <53F4A888.10302@johnc57uk.plus.com> Hi Phil et al, Having been around in Ham radio for a good long while now, I have seen many changes and advancements in the hobby over the many years but none as exciting as this. I would like to echo Jeff's sentiments G0AFQ, and express how sincerely grateful I am to yourself Phil, and all the others who have contributed to the HPSDR project and from whom I've benefited. I have a Hermes board and homebrew low power PA which works extremely well and is a pleasure to use. In my view it easily out performs my Yaesu and Icom transceivers on receive. When I complete the high power PA it will no doubt out perfom on tx as well. I have earwigged on the side for a long while now monitoring developments and comments with interest. Next step is to purchase a Jetson TK1 SBC and attempt to build cuSDR on that. Again my heartfelt thanks. 73s John G3VRF From chris at vspl.co.uk Wed Aug 20 07:12:21 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 15:12:21 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> References: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> Message-ID: <20140820141226.1ED8248937@diego.dreamhost.com> Hi Phil Not sure you meant J5 - that seems to be the I2C data bypass jumper. J9 HDR 5P TEST seems to have some interesting/useful I/O pins. Is that what you meant? 73 Chris G4NUX On 20 Aug 2014, at 12:37, Phil Harman wrote: > Hi Chris. > > Alternatively, you could make a small PCB that plugged into J5 on Mercury that held the PHY, 25MHz clock and Ethernet socket. Since you no longer need any DDC code in the FPGA you would have plenty of room to house the raw Ethernet code. > > 'Weekend Project' anyone ? > > 73 Phil....VK6PH > > > > > > -----Original Message----- From: Chris Smith > Sent: Wednesday, August 20, 2014 4:48 PM > To: phil at pharman.org > Cc: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > Hi Phil > > I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) > > Cheers > > Chris > > > On 20 Aug 2014, at 09:22, "Phil Harman" wrote: > >> Hi Chris, >> >> The limitation of using the Mercury board together with Metis is the >> bandwidth of the Alex bus. >> >> If would could couple the two boards together in a suitable way then we >> can use the existing Mercury board. >> >> 73 Phil...VK6PH >> >> >>> Hi Phil >>> >>> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >>> that DFC was the way things were going. Which is why I jumped on the TK1 >>> bandwagon. >>> >>> Will there ever be a way of using the Mercury front end to supply the raw >>> packets, perhaps with a bespoke daughter board? >>> >>> Congrats to John whom I had the pleasure of speaking to at Friedrischafen. >>> I'm sure we all look forward to the new era of SDR in the amateur radio >>> arena. >>> >>> Cheers & 73 >>> >>> Chris G4NUX >>> >>> On 20 Aug 2014, at 08:31, Phil Harman wrote: >>> >>>> ***** High Performance Software Defined Radio Discussion List ***** >>>> >>>> All, >>>> >>>> I'm delighted to be able to report that we have been able to develop, to >>>> proof-of-concept stage, a new SDR architecture. >>>> >>>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>>> DDC, >>>> in order to provide (multiple) receivers. Whist this is quite >>>> effective, >>>> much of the initial DSP work is done using FPGAs, or a combination of >>>> FPGA >>>> plus dedicated DSP chips and microprocessors, rather than totally within >>>> the PC. >>>> >>>> As more complex features are added, the size and complexity of the FPGA >>>> and DSP code increases. The skills to write, debug and maintain this >>>> code >>>> is only available via a small percentage of software engineers, or >>>> enthusiasts, in comparison to those able to write code for PC based >>>> hardware. >>>> >>>> In order to open the SDR world to those with PC software skills we are >>>> in >>>> the process of developing a new SDR architecture. >>>> >>>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>>> time and passes the 'raw' samples directly to an associated computer. >>>> >>>> This computer then calculates the FFT of the raw samples and >>>> subsequently >>>> processes the result as the user requires. >>>> >>>> This is not a totally new concept since both the cuSDR and KISS Konsole >>>> software uses raw ADC samples to provide the wideband bandscope >>>> displays. >>>> >>>> However, for this requirement the FFT only needs to be done at the >>>> bandscope update rate of a few 10's of times per second, which hardly >>>> taxes a modern PC at all. >>>> >>>> The new concept requires that we take the FFT of all samples in >>>> real-time. >>>> >>>> This has been possible in the past - if you had access to a Cray super >>>> computer! >>>> >>>> Well now we do have access to very low cost computers that provide the >>>> processing power we need. One example of this is the new Nvidia Jetson >>>> TK1 single board computer. At a cost of $192 this board contains four >>>> ARM >>>> CPUs plus 192 CUDA processors. >>>> >>>> More details of this remarkable board can be found here: >>>> >>>> https://developer.nvidia.com/jetson-tk1 >>>> >>>> Since the CUDA cores can process data in parallel, we can use these to >>>> perform the high speed FFT. >>>> >>>> John, G0ORX, has written preliminary code for the Jetson board and has >>>> confirmed that it has the necessary performance we require. >>>> >>>> The test environment consisted of a Jetson board connected via Gigabit >>>> Ethernet to an Angelia board. A special version of FPGA code was >>>> written >>>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>>> the >>>> Jetson board. >>>> >>>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>>> >>>> Whilst it's still early days, and there is much more to be done, this >>>> critical early success does indicate that this new architecture has a >>>> very >>>> promising future. >>>> >>>> The Jetson board is taking the role of an 'SDR Server' which I have >>>> written about in the past. >>>> >>>> In which case what benefits does this new architecture provide to >>>> openHPSR? >>>> >>>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>>> and hence uses a small percentage of the space available with a >>>> subsequent >>>> reduction in power consumption. >>>> >>>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>>> simplified since the SDR hardware only has to connect to a single, >>>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>>> required. The SDR Server simply needs to know the MAC address of the >>>> SDR >>>> hardware in order to communicate. It should be possible for a single >>>> SDR >>>> hardware board to feed multiple SDR Servers, but that's something for >>>> the >>>> future. >>>> >>>> 3. Virtually all the signal processing is undertaken on the associated >>>> single board computer (SBC) or (suitable) PC. If sufficient processing >>>> power is available then the GUI can run on the same SBC. Alternatively >>>> the >>>> user's normal PC (which does not require to be high performance since it >>>> does not do any significant digital signal processing) or a Tablet, cell >>>> phone etc could be used. >>>> >>>> 4. Many more users have the necessary skills and experience to support, >>>> maintain and further develop the code. New features are added to the SDR >>>> Server code rather than the FPGA code. >>>> >>>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>>> FPGA >>>> and/or power supply restrictions may have limited adding new features. >>>> >>>> 6. Future hardware upgrades will be to the associated SBC where faster >>>> and >>>> lower cost options can be expected. Nvidia have already indicated that >>>> a >>>> 64 bit board will be available in the near future. >>>> >>>> 7. Remote access to an SDR via the Internet will enable multiple users >>>> to >>>> share the SDR with each selecting their desired frequency, bandwidth and >>>> mode. >>>> >>>> There are other potential benefits relating to simpler and lower cost >>>> SDR >>>> hardware, but that is for the future. >>>> >>>> For want of a name we are calling this new architecture 'Direct Fourier >>>> Conversion' (DFC). >>>> >>>> For those that are already experimenting with the Jetson board we do >>>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>>> and >>>> I will advise when, and where, this is available. >>>> >>>> John's code is presently not available, so please don't pester him, but >>>> as >>>> soon as it reaches Beta stage it will be released. >>>> >>>> Please join me in congratulating John on this exciting development. >>>> >>>> 73 Phil....VK6PH >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> HPSDR Discussion List >>>> To post msg: hpsdr at openhpsdr.org >>>> Subscription help: >>>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>>> HPSDR web page: http://openhpsdr.org >>>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >>> >>> >>> >> > > > --- > This email is free from viruses and malware because avast! Antivirus protection is active. > http://www.avast.com From chris at vspl.co.uk Wed Aug 20 07:19:06 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 15:19:06 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <20140820141226.1ED8248937@diego.dreamhost.com> References: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> <20140820141226.1ED8248937@diego.dreamhost.com> Message-ID: <20140820141910.E5D7A489DF@diego.dreamhost.com> Whoops! No, I need to get some new glasses. J5 20-pin header has a whole bunch of good stuff on it. Sorry. 73 Chris G4NUX On 20 Aug 2014, at 15:12, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Phil > > Not sure you meant J5 - that seems to be the I2C data bypass jumper. J9 HDR 5P TEST seems to have some interesting/useful I/O pins. Is that what you meant? > > 73 Chris G4NUX > > On 20 Aug 2014, at 12:37, Phil Harman wrote: > >> Hi Chris. >> >> Alternatively, you could make a small PCB that plugged into J5 on Mercury that held the PHY, 25MHz clock and Ethernet socket. Since you no longer need any DDC code in the FPGA you would have plenty of room to house the raw Ethernet code. >> >> 'Weekend Project' anyone ? >> >> 73 Phil....VK6PH >> >> >> >> >> >> -----Original Message----- From: Chris Smith >> Sent: Wednesday, August 20, 2014 4:48 PM >> To: phil at pharman.org >> Cc: hpsdr at lists.openhpsdr.org >> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >> >> Hi Phil >> >> I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) >> >> Cheers >> >> Chris >> >> >> On 20 Aug 2014, at 09:22, "Phil Harman" wrote: >> >>> Hi Chris, >>> >>> The limitation of using the Mercury board together with Metis is the >>> bandwidth of the Alex bus. >>> >>> If would could couple the two boards together in a suitable way then we >>> can use the existing Mercury board. >>> >>> 73 Phil...VK6PH >>> >>> >>>> Hi Phil >>>> >>>> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >>>> that DFC was the way things were going. Which is why I jumped on the TK1 >>>> bandwagon. >>>> >>>> Will there ever be a way of using the Mercury front end to supply the raw >>>> packets, perhaps with a bespoke daughter board? >>>> >>>> Congrats to John whom I had the pleasure of speaking to at Friedrischafen. >>>> I'm sure we all look forward to the new era of SDR in the amateur radio >>>> arena. >>>> >>>> Cheers & 73 >>>> >>>> Chris G4NUX >>>> >>>> On 20 Aug 2014, at 08:31, Phil Harman wrote: >>>> >>>>> ***** High Performance Software Defined Radio Discussion List ***** >>>>> >>>>> All, >>>>> >>>>> I'm delighted to be able to report that we have been able to develop, to >>>>> proof-of-concept stage, a new SDR architecture. >>>>> >>>>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>>>> DDC, >>>>> in order to provide (multiple) receivers. Whist this is quite >>>>> effective, >>>>> much of the initial DSP work is done using FPGAs, or a combination of >>>>> FPGA >>>>> plus dedicated DSP chips and microprocessors, rather than totally within >>>>> the PC. >>>>> >>>>> As more complex features are added, the size and complexity of the FPGA >>>>> and DSP code increases. The skills to write, debug and maintain this >>>>> code >>>>> is only available via a small percentage of software engineers, or >>>>> enthusiasts, in comparison to those able to write code for PC based >>>>> hardware. >>>>> >>>>> In order to open the SDR world to those with PC software skills we are >>>>> in >>>>> the process of developing a new SDR architecture. >>>>> >>>>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>>>> time and passes the 'raw' samples directly to an associated computer. >>>>> >>>>> This computer then calculates the FFT of the raw samples and >>>>> subsequently >>>>> processes the result as the user requires. >>>>> >>>>> This is not a totally new concept since both the cuSDR and KISS Konsole >>>>> software uses raw ADC samples to provide the wideband bandscope >>>>> displays. >>>>> >>>>> However, for this requirement the FFT only needs to be done at the >>>>> bandscope update rate of a few 10's of times per second, which hardly >>>>> taxes a modern PC at all. >>>>> >>>>> The new concept requires that we take the FFT of all samples in >>>>> real-time. >>>>> >>>>> This has been possible in the past - if you had access to a Cray super >>>>> computer! >>>>> >>>>> Well now we do have access to very low cost computers that provide the >>>>> processing power we need. One example of this is the new Nvidia Jetson >>>>> TK1 single board computer. At a cost of $192 this board contains four >>>>> ARM >>>>> CPUs plus 192 CUDA processors. >>>>> >>>>> More details of this remarkable board can be found here: >>>>> >>>>> https://developer.nvidia.com/jetson-tk1 >>>>> >>>>> Since the CUDA cores can process data in parallel, we can use these to >>>>> perform the high speed FFT. >>>>> >>>>> John, G0ORX, has written preliminary code for the Jetson board and has >>>>> confirmed that it has the necessary performance we require. >>>>> >>>>> The test environment consisted of a Jetson board connected via Gigabit >>>>> Ethernet to an Angelia board. A special version of FPGA code was >>>>> written >>>>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>>>> the >>>>> Jetson board. >>>>> >>>>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>>>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>>>> >>>>> Whilst it's still early days, and there is much more to be done, this >>>>> critical early success does indicate that this new architecture has a >>>>> very >>>>> promising future. >>>>> >>>>> The Jetson board is taking the role of an 'SDR Server' which I have >>>>> written about in the past. >>>>> >>>>> In which case what benefits does this new architecture provide to >>>>> openHPSR? >>>>> >>>>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>>>> and hence uses a small percentage of the space available with a >>>>> subsequent >>>>> reduction in power consumption. >>>>> >>>>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>>>> simplified since the SDR hardware only has to connect to a single, >>>>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>>>> required. The SDR Server simply needs to know the MAC address of the >>>>> SDR >>>>> hardware in order to communicate. It should be possible for a single >>>>> SDR >>>>> hardware board to feed multiple SDR Servers, but that's something for >>>>> the >>>>> future. >>>>> >>>>> 3. Virtually all the signal processing is undertaken on the associated >>>>> single board computer (SBC) or (suitable) PC. If sufficient processing >>>>> power is available then the GUI can run on the same SBC. Alternatively >>>>> the >>>>> user's normal PC (which does not require to be high performance since it >>>>> does not do any significant digital signal processing) or a Tablet, cell >>>>> phone etc could be used. >>>>> >>>>> 4. Many more users have the necessary skills and experience to support, >>>>> maintain and further develop the code. New features are added to the SDR >>>>> Server code rather than the FPGA code. >>>>> >>>>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>>>> FPGA >>>>> and/or power supply restrictions may have limited adding new features. >>>>> >>>>> 6. Future hardware upgrades will be to the associated SBC where faster >>>>> and >>>>> lower cost options can be expected. Nvidia have already indicated that >>>>> a >>>>> 64 bit board will be available in the near future. >>>>> >>>>> 7. Remote access to an SDR via the Internet will enable multiple users >>>>> to >>>>> share the SDR with each selecting their desired frequency, bandwidth and >>>>> mode. >>>>> >>>>> There are other potential benefits relating to simpler and lower cost >>>>> SDR >>>>> hardware, but that is for the future. >>>>> >>>>> For want of a name we are calling this new architecture 'Direct Fourier >>>>> Conversion' (DFC). >>>>> >>>>> For those that are already experimenting with the Jetson board we do >>>>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>>>> and >>>>> I will advise when, and where, this is available. >>>>> >>>>> John's code is presently not available, so please don't pester him, but >>>>> as >>>>> soon as it reaches Beta stage it will be released. >>>>> >>>>> Please join me in congratulating John on this exciting development. >>>>> >>>>> 73 Phil....VK6PH >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> HPSDR Discussion List >>>>> To post msg: hpsdr at openhpsdr.org >>>>> Subscription help: >>>>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>>>> HPSDR web page: http://openhpsdr.org >>>>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >>>> >>>> >>>> >>> >> >> >> --- >> This email is free from viruses and malware because avast! Antivirus protection is active. >> http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From mark at buttery.org Wed Aug 20 07:20:53 2014 From: mark at buttery.org (=?UTF-8?B?U2hpcmxleSBNw6FycXVleiBEw7psY2V5?=) Date: Wed, 20 Aug 2014 10:20:53 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <000001cfbc53$85bf7be0$913e73a0$@de> References: <000001cfbc53$85bf7be0$913e73a0$@de> Message-ID: > Congratulations. Maybe a stupid question: Current bottleneck is the 1 Gbit/s > LAN connection that makes a decimation by factor 2 necessary or limits the > frequency range to 33MHz, i.e. we lose 6m band at least as raw I/Q. Is > there no (economic) way to get the LAN connection faster? 14 and 16 Bit > ADC/DACs are getting faster and low-jitter sampling oscillators up to 300MHz > are available, hence a lot of nice applications are imaginable, hi. With the current boards there may not be. But a variety of standardized higher speed interfaces are available, including eSATA, Thunderbolt, USB 3.0, and 10G Ethernet. A future design could move to one of those. From meijer.ha at home.nl Wed Aug 20 08:29:00 2014 From: meijer.ha at home.nl (H.A.Meijer) Date: Wed, 20 Aug 2014 17:29:00 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> References: <53F46332.9040601@home.nl> <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> Message-ID: <53F4BEBC.9080105@home.nl> Hi Phil, So, just to simplify, so that I also understand, this Jetson board could replace (more or less) the on-board FPGA, being more powerful(?) and easier to code for the more 'average' software engineer?. And the (high performance) (W)DSP software, that's now running on or PC's, can easily by done by that board? and not just some very basic DSP work, I see at some 'other' popular sdr transceiver. The only problem I see for now is that there will be an extra 'data highway', between the sdr hardware and the end-user interface PC, that could coarse extra problems/latency..etc.. We will see what the future brings. Thanks, 73 Bert PA2XHF Phil Harman schreef op 20-8-2014 om 13:15: > Hi Bert, > Yes, as we are today the ?new board? is connected between your SDR > hardware and your PC. > It may be possible to run both the SDR server and Client GUI software > on the one SBC or PC. Its a little early yet to know if the Jetson > board is capable of doing this. > If so, then with your SDR hardware you would have a dedicated SDR that > does not require an additional PC. This could all be packaged into a > case with a suitable touch screen etc. > You can always do that today by using a suitable SBC that will run > Windows. > 73 Phil...VK6PH > > > > ------------------------------------------------------------------------ > --- Dit e-mailbericht bevat geen virussen en malware omdat avast! Antivirus-bescherming actief is. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dc6ny at gmx.de Wed Aug 20 10:55:20 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Wed, 20 Aug 2014 19:55:20 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <000001cfbc53$85bf7be0$913e73a0$@de> Message-ID: <000001cfbc9f$e8de2bd0$ba9a8370$@de> Thanks for reply, Mark. 73, Helmut -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von Shirley M?rquez D?lcey Gesendet: Mittwoch, 20. August 2014 16:21 An: hpsdr at lists.openhpsdr.org Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** > Congratulations. Maybe a stupid question: Current bottleneck is the 1 > Gbit/s LAN connection that makes a decimation by factor 2 necessary or > limits the frequency range to 33MHz, i.e. we lose 6m band at least as > raw I/Q. Is there no (economic) way to get the LAN connection faster? > 14 and 16 Bit ADC/DACs are getting faster and low-jitter sampling > oscillators up to 300MHz are available, hence a lot of nice applications are imaginable, hi. With the current boards there may not be. But a variety of standardized higher speed interfaces are available, including eSATA, Thunderbolt, USB 3.0, and 10G Ethernet. A future design could move to one of those. _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From doug at dougronald.com Wed Aug 20 11:22:33 2014 From: doug at dougronald.com (Doug Ronald) Date: Wed, 20 Aug 2014 11:22:33 -0700 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <007a01cfbca3$b7bfb880$273f2980$@dougronald.com> Hi, Could you give some idea of what is the present capability with regard to FFT's per second, and the bin size? I mean extracting from the information bandwidth for communications purposes, not simply for the frequency domain display. I'm curious to know if this would allow one to FFT over a 30 MHz bandwidth to say a 500 Hz bandwidth or even a 2.4 kHz bandwidth. That would be extremely useful. Thanks, -Doug Ronald AE6SY -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Phil Harman Sent: Wednesday, August 20, 2014 12:31 AM To: hpsdr at lists.openhpsdr.org Subject: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. In order to open the SDR world to those with PC software skills we are in the process of developing a new SDR architecture. This architecture digitises the entire 0 to 30MHz radio spectrum in real time and passes the 'raw' samples directly to an associated computer. This computer then calculates the FFT of the raw samples and subsequently processes the result as the user requires. This is not a totally new concept since both the cuSDR and KISS Konsole software uses raw ADC samples to provide the wideband bandscope displays. However, for this requirement the FFT only needs to be done at the bandscope update rate of a few 10's of times per second, which hardly taxes a modern PC at all. The new concept requires that we take the FFT of all samples in real-time. This has been possible in the past - if you had access to a Cray super computer! Well now we do have access to very low cost computers that provide the processing power we need. One example of this is the new Nvidia Jetson TK1 single board computer. At a cost of $192 this board contains four ARM CPUs plus 192 CUDA processors. More details of this remarkable board can be found here: https://developer.nvidia.com/jetson-tk1 Since the CUDA cores can process data in parallel, we can use these to perform the high speed FFT. John, G0ORX, has written preliminary code for the Jetson board and has confirmed that it has the necessary performance we require. The test environment consisted of a Jetson board connected via Gigabit Ethernet to an Angelia board. A special version of FPGA code was written for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the Jetson board. We used raw Ethernet frames over the Gigabit link, in order to maximise the link bandwidth, since we require a sustained 983Mbps transfer rate. Whilst it's still early days, and there is much more to be done, this critical early success does indicate that this new architecture has a very promising future. The Jetson board is taking the role of an 'SDR Server' which I have written about in the past. In which case what benefits does this new architecture provide to openHPSR? 1. The FPGA code is greatly simplified, is easier to write and maintain, and hence uses a small percentage of the space available with a subsequent reduction in power consumption. 2. The protocol between the SDR hardware and the SDR Server is greatly simplified since the SDR hardware only has to connect to a single, dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer required. The SDR Server simply needs to know the MAC address of the SDR hardware in order to communicate. It should be possible for a single SDR hardware board to feed multiple SDR Servers, but that's something for the future. 3. Virtually all the signal processing is undertaken on the associated single board computer (SBC) or (suitable) PC. If sufficient processing power is available then the GUI can run on the same SBC. Alternatively the user's normal PC (which does not require to be high performance since it does not do any significant digital signal processing) or a Tablet, cell phone etc could be used. 4. Many more users have the necessary skills and experience to support, maintain and further develop the code. New features are added to the SDR Server code rather than the FPGA code. 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA and/or power supply restrictions may have limited adding new features. 6. Future hardware upgrades will be to the associated SBC where faster and lower cost options can be expected. Nvidia have already indicated that a 64 bit board will be available in the near future. 7. Remote access to an SDR via the Internet will enable multiple users to share the SDR with each selecting their desired frequency, bandwidth and mode. There are other potential benefits relating to simpler and lower cost SDR hardware, but that is for the future. For want of a name we are calling this new architecture 'Direct Fourier Conversion' (DFC). For those that are already experimenting with the Jetson board we do intend to release the DFC FPGA code for both Angelia and Hermes boards and I will advise when, and where, this is available. John's code is presently not available, so please don't pester him, but as soon as it reaches Beta stage it will be released. Please join me in congratulating John on this exciting development. 73 Phil....VK6PH _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From jm-hpsdr at themarvins.org Wed Aug 20 12:57:07 2014 From: jm-hpsdr at themarvins.org (John Marvin) Date: Wed, 20 Aug 2014 13:57:07 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F4FD93.900@themarvins.org> I see no mention of the transmit side. I assume the current prototype (FPGA in particular) is a receive only implementation? Is DUC still the planned approach for transmit? I may get my 12 receivers (simultanous WSPR reception on all current and experimental ham bands 10m and below) on Hermes yet! Thanks for the update, John AC0ZG On 8/20/2014 1:31 AM, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From douglas.adams at me.com Wed Aug 20 17:11:51 2014 From: douglas.adams at me.com (Doug Adams) Date: Wed, 20 Aug 2014 20:11:51 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: Phil, This all sounds great, I'm all for advancing the "state-of-the-art". It would be great if an option was to have the SBC on a PCIE bus, that way it could be placed directly into a computer with such an interface (most PC's) or put into a PCIE Expansion box (e.g. a Mac expansion box fed by a Thunderbolt cable). That would get us a very high speed connection to the device and some OS independence. Does this also mean that the proposed changes to the Metis / Hermes protocol from the "Discussion Paper - openHPSDR Ethernet Protocol" are not going to be done? 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at pharman.org Wed Aug 20 17:24:01 2014 From: phil at pharman.org (Phil Harman) Date: Thu, 21 Aug 2014 08:24:01 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F4FD93.900@themarvins.org> References: <53F4FD93.900@themarvins.org> Message-ID: <6226ab1d7b126fbb9ea9a51ba1e90654.squirrel@webmail.eftel.com.au> Hi John, Doing a similar approach for the transmitter is something for the future. If you only want 12 receivers then we can reduce it to that number :) 73 Phil... > ***** High Performance Software Defined Radio Discussion List ***** > > I see no mention of the transmit side. I assume the current prototype > (FPGA in particular) is a receive only implementation? Is DUC still the > planned approach for transmit? > > I may get my 12 receivers (simultanous WSPR reception on all current and > experimental ham bands 10m and below) on Hermes yet! > > Thanks for the update, > > John > AC0ZG > > On 8/20/2014 1:31 AM, Phil Harman wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> I'm delighted to be able to report that we have been able to develop, to >> proof-of-concept stage, a new SDR architecture. >> >> Current SDRs use the software equivalent of zero IF techniques, i.e. >> DDC, >> in order to provide (multiple) receivers. Whist this is quite >> effective, >> much of the initial DSP work is done using FPGAs, or a combination of >> FPGA >> plus dedicated DSP chips and microprocessors, rather than totally within >> the PC. >> >> As more complex features are added, the size and complexity of the FPGA >> and DSP code increases. The skills to write, debug and maintain this >> code >> is only available via a small percentage of software engineers, or >> enthusiasts, in comparison to those able to write code for PC based >> hardware. >> >> In order to open the SDR world to those with PC software skills we are >> in >> the process of developing a new SDR architecture. >> >> This architecture digitises the entire 0 to 30MHz radio spectrum in real >> time and passes the 'raw' samples directly to an associated computer. >> >> This computer then calculates the FFT of the raw samples and >> subsequently >> processes the result as the user requires. >> >> This is not a totally new concept since both the cuSDR and KISS Konsole >> software uses raw ADC samples to provide the wideband bandscope >> displays. >> >> However, for this requirement the FFT only needs to be done at the >> bandscope update rate of a few 10's of times per second, which hardly >> taxes a modern PC at all. >> >> The new concept requires that we take the FFT of all samples in >> real-time. >> >> This has been possible in the past - if you had access to a Cray super >> computer! >> >> Well now we do have access to very low cost computers that provide the >> processing power we need. One example of this is the new Nvidia Jetson >> TK1 single board computer. At a cost of $192 this board contains four >> ARM >> CPUs plus 192 CUDA processors. >> >> More details of this remarkable board can be found here: >> >> https://developer.nvidia.com/jetson-tk1 >> >> Since the CUDA cores can process data in parallel, we can use these to >> perform the high speed FFT. >> >> John, G0ORX, has written preliminary code for the Jetson board and has >> confirmed that it has the necessary performance we require. >> >> The test environment consisted of a Jetson board connected via Gigabit >> Ethernet to an Angelia board. A special version of FPGA code was >> written >> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >> the >> Jetson board. >> >> We used raw Ethernet frames over the Gigabit link, in order to maximise >> the link bandwidth, since we require a sustained 983Mbps transfer rate. >> >> Whilst it's still early days, and there is much more to be done, this >> critical early success does indicate that this new architecture has a >> very >> promising future. >> >> The Jetson board is taking the role of an 'SDR Server' which I have >> written about in the past. >> >> In which case what benefits does this new architecture provide to >> openHPSR? >> >> 1. The FPGA code is greatly simplified, is easier to write and maintain, >> and hence uses a small percentage of the space available with a >> subsequent >> reduction in power consumption. >> >> 2. The protocol between the SDR hardware and the SDR Server is greatly >> simplified since the SDR hardware only has to connect to a single, >> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >> required. The SDR Server simply needs to know the MAC address of the >> SDR >> hardware in order to communicate. It should be possible for a single >> SDR >> hardware board to feed multiple SDR Servers, but that's something for >> the >> future. >> >> 3. Virtually all the signal processing is undertaken on the associated >> single board computer (SBC) or (suitable) PC. If sufficient processing >> power is available then the GUI can run on the same SBC. Alternatively >> the >> user's normal PC (which does not require to be high performance since it >> does not do any significant digital signal processing) or a Tablet, cell >> phone etc could be used. >> >> 4. Many more users have the necessary skills and experience to support, >> maintain and further develop the code. New features are added to the SDR >> Server code rather than the FPGA code. >> >> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >> FPGA >> and/or power supply restrictions may have limited adding new features. >> >> 6. Future hardware upgrades will be to the associated SBC where faster >> and >> lower cost options can be expected. Nvidia have already indicated that >> a >> 64 bit board will be available in the near future. >> >> 7. Remote access to an SDR via the Internet will enable multiple users >> to >> share the SDR with each selecting their desired frequency, bandwidth and >> mode. >> >> There are other potential benefits relating to simpler and lower cost >> SDR >> hardware, but that is for the future. >> >> For want of a name we are calling this new architecture 'Direct Fourier >> Conversion' (DFC). >> >> For those that are already experimenting with the Jetson board we do >> intend to release the DFC FPGA code for both Angelia and Hermes boards >> and >> I will advise when, and where, this is available. >> >> John's code is presently not available, so please don't pester him, but >> as >> soon as it reaches Beta stage it will be released. >> >> Please join me in congratulating John on this exciting development. >> >> 73 Phil....VK6PH >> >> >> >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > From wb4gcs at wb4gcs.org Wed Aug 20 17:37:23 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Wed, 20 Aug 2014 20:37:23 -0400 Subject: [hpsdr] Interesting email on SDR transmit noise In-Reply-To: <5261FFA0.8080001@tx.rr.com> References: <5261FFA0.8080001@tx.rr.com> Message-ID: <53F53F43.5010205@wb4gcs.org> WOW! Has anybody made similar measurements on Penny/Munim?? 73, Jim wb4gcs at amsat.org On 10/18/2013 11:42 PM, KA5FPT Paul wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I saw the following on the Flexradio mail list. I am having some > problems understanding how a SDR transmitter can cause wide band > noise. I would have thought that with proper filtering it would be > controlled. > ----------------------------------------------------------------------------------------------- > > > Date: Wed, 16 Oct 2013 14:59:37 -0400 > From: "Gedas" > To: > Subject: [Flexradio] Noise Sidebands, Article by SM5BSZ > Message-ID: <399ADD464530473F88C1CBF0659768F5 at biggy> > Content-Type: text/plain; charset="utf-8" > > I came across this interesting article by SM5BSZ who discusses some > possible transmitter issues with many radios, including the Flex. It > has me a bit concerned. I am wondering if anyone has seen similar > data for the Flex 5000? The article may be found here: > > http://www.sm5bsz.com/dynrange/dubus313.pdf > > Gedas, W8BYA > Gallery athttp://w8bya.com > Light travels faster than sound.... > This is why some people appear bright until you hear them speak. > > -------------------------------------------------------------------------------------------------- > > > 73, > Paul Cecil > KA5FPT > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From phil at pharman.org Wed Aug 20 17:53:29 2014 From: phil at pharman.org (Phil Harman) Date: Thu, 21 Aug 2014 08:53:29 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F4BEBC.9080105@home.nl> References: <53F46332.9040601@home.nl> <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> <53F4BEBC.9080105@home.nl> Message-ID: Hi Bert, > So, just to simplify, so that I also understand, this Jetson board > could replace (more or less) the on-board FPGA, > being more powerful(?) and easier to code for the more 'average' > software engineer?. Yes, it does replace a large percentage of the FPGA code, not so sure about more powerful, but many more enthusiasts will be able to contribute. If there is enough spare capacity, or a future board has, then it could also replace the PC. > And the (high performance) (W)DSP software, that's now running on or > PC's, can easily by done by that board? > and not just some very basic DSP work, I see at some 'other' popular sdr > transceiver. Yes. > The only problem I see for now is that there will be an extra 'data > highway', between the sdr hardware > and the end-user interface PC, that could coarse extra > problems/latency..etc.. The data between the SDR Server and PC will only be low bandwidth. The Audio and bandscope data can be compressed so that we are perhaps only looking at 200kbps or even less. For digital modes it may be necessary to send I&Q data to the PC which will increase the bandwidth required. > We will see what the future brings. Yes, early days for DFC yet. We still have a lot to learn! 73 Phil...VK6PH From jm-hpsdr at themarvins.org Wed Aug 20 20:35:16 2014 From: jm-hpsdr at themarvins.org (John Marvin) Date: Wed, 20 Aug 2014 21:35:16 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <6226ab1d7b126fbb9ea9a51ba1e90654.squirrel@webmail.eftel.com.au> References: <53F4FD93.900@themarvins.org> <6226ab1d7b126fbb9ea9a51ba1e90654.squirrel@webmail.eftel.com.au> Message-ID: <53F568F4.3070204@themarvins.org> Oh, I'm quite aware that with this architecture the number of receivers is purely limited by the processing power and bandwidth you can apply to the problem. I look forward to playing with a fpga supporting this for Hermes. With this architecture it might make more sense for many use cases to do the I/O on the SBC (i.e. mike/line in and headphone/speaker out), but I hope that you will also preserve the capability of using the onboard Hermes I/O, i.e. still provide a synchronous mike stream with the single ultra wide data receive stream, and a synchronous speaker headphone channel, along with the control necessary to support them. Thanks, John On 8/20/2014 6:24 PM, Phil Harman wrote: > Hi John, > > Doing a similar approach for the transmitter is something for the future. > > If you only want 12 receivers then we can reduce it to that number :) > > 73 Phil... > > > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> I see no mention of the transmit side. I assume the current prototype >> (FPGA in particular) is a receive only implementation? Is DUC still the >> planned approach for transmit? >> >> I may get my 12 receivers (simultanous WSPR reception on all current and >> experimental ham bands 10m and below) on Hermes yet! >> >> Thanks for the update, >> >> John >> AC0ZG >> >> From lstoskopf at cox.net Thu Aug 21 07:55:49 2014 From: lstoskopf at cox.net (lstoskopf at cox.net) Date: Thu, 21 Aug 2014 10:55:49 -0400 Subject: [hpsdr] HackRF tutorial Message-ID: <20140821105549.YWEKY.153771.imail@eastrmwml106> Perhaps of interest: http://greatscottgadgets.com/sdr N0UU From peroy at broadpark.no Thu Aug 21 12:05:42 2014 From: peroy at broadpark.no (=?iso-8859-1?Q?=22Per_=D8yvind_Jonsson=22?=) Date: Thu, 21 Aug 2014 21:05:42 +0200 Subject: [hpsdr] Common Hermes firmware for Anan/Alex/Apollo? Message-ID: <77c0b3bd26a74.53f65f26@broadpark.no> First, thank you to the gurus for the fantastic effort with hardware, firmware and software! There is however one Hermes issue which begs to be solved, both to reduce user confusion, and hopefully also the effort needed to update the firmware. Today we need two Hermes FW versions. My understanding is that this is because the ANAN-10 and ALEX filters have different cut-off frequencies. It would of course be nice if Hermes could auto-detect which filter board is connected, but based on the schematics I have seen this will require some hardware modifications. Possible, but not desirable. When setting up PowerSDR we already need to specify the radio model, and some of this information is sent to Hermes. Would it be possible to extend this to also send information on which filter board is used? This could allow the FW to set the proper filter parameters. According to the USB_protocol_V1.58 there does not seem to be any bits that could be used directly, but it may be possible to use some otherwise unused combinations. One possibility seems to be to use C2 in the sequence starting with C0 = 0001001x, like this: bit 7: VNA mode (no change) bit 6: Alex manual (no change) bit 5: Hermes filter board (0 = Alex or ANAN, 1 = Apollo) bit 4-3-2: If bit 5 = 1 sets Apollo options (no change) If bit 5 = 0 could be used to specify which board(s) like so: 000 - None 001 - Alex RX 010 - Alex TX 011 - Alex RX+TX 100 - ANAN-10 other combinations available for future boards? bit 1: Metis/Penelope etc Mic/Line In (no change) bit 0: Hermes etc Mic Boost (no change) Thoughts/comments? LA9WX -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at foxgulch.com Fri Aug 22 09:41:09 2014 From: larry at foxgulch.com (Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop) Date: Fri, 22 Aug 2014 10:41:09 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> Message-ID: <53F772A5.9050001@foxgulch.com> Attempted to upgrade the firmware in my 100D using HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when I attempted to write 4.1 rbf, all operations stopped. Now it won't boot. (J17 jumper on or off, doesn't help) So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and fired off the Altera Quartus Programmer v12 build 177 11/7/2012 which responded after I clicked Start as follows: Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 2014 Info (209018): Device 1 silicon ID is 0x18 Info (209044): Erasing ASP configuration device(s) Info (209024): Programming device 1 Info (209018): Device 1 silicon ID is 0x18 Info (209011): Successfully performed operation(s) Info (209061): Ended Programmer operation at Fri Aug 22 15:26:15 2014 which looked OK but no boot! Second from left front panel red led glows constantly but dim. Somewhere I noticed (post by Franz Hegener) that I should have selected EPC 128? My device (in the Quartus II 32 bit Programmer window shows Device=EPCS16 as read from Quartus-II Programmer window and also shown in the document "Quartus-II Programmer and Byteblaster" by N9VV and KCXG v2.3 dated 04/23/13. Is this my error? Any ideas to try next?? Thanks, Larry W0AY Note for record: 1. Version 12 of the Quartus II Programmer matches the "Quartus-II Programmer and Byteblaster" instructions (noted above) but the current version V12 does not. Obtain V12 here: https://www.altera.com/download/sw/dnl-sw-index.jsp# 2. Win7 refused to load the drivers provided by Altera in V14. I used the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 From k5so at valornet.com Fri Aug 22 10:20:32 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Fri, 22 Aug 2014 11:20:32 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: <53F772A5.9050001@foxgulch.com> References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: Hi Larry, Sorry to hear you?re having trouble programming your 100D. I suspect that when you first had your problem you could?ve recovered by using Bootloader mode, but perhaps something went awry. No problem, it?s all recoverable no matter what you did. Sounds like you have the Quartus II Programmer and your blaster cable talking fine to each other so you needn?t worry about trying to load v14 Quartus from Altera (in fact, I recommend not using v14). Here I use Quartus II v13.0 for most of my work but the Quartus II Programmer in v12 or likely any other earlier version will work to program an EEPROM config device so I wouldn?t worry about finding a particular version of Quartus II Programmer; it?s not that critical which you use, generally (at least in my experience). The Angelia board uses an EPCS128 EEPROM configuration device (not an EPCS16) so that is the device you should specify in the Quartus II Programmer. You should be plugging your blaster cable onto P2 and loading the file ?output_file.pof? for Angelia. The ?output_file.pof? contains both the bootloader code and the binary FPGA image that gets loaded later into the FPGA. If you erroneously load ?Angelia.pof? you will not be loading the bootloader code into the EEPROM with the FPGA image, you?ll only be loading the FPGA image. It will run and come up on power up but there is not bootloader code in it so should you later wish to use ?Bootloader? mode you cannot. Use the ?output_file.pof? to load into the EEPROM and you?ll be good. 73, Joe K5SO On Aug 22, 2014, at 10:41 AM, Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Attempted to upgrade the firmware in my 100D using HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when I attempted to write 4.1 rbf, all operations stopped. Now it won't boot. (J17 jumper on or off, doesn't help) > > So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and fired off the Altera Quartus Programmer v12 build 177 11/7/2012 which responded after I clicked Start as follows: > > Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 2014 > Info (209018): Device 1 silicon ID is 0x18 > Info (209044): Erasing ASP configuration device(s) > Info (209024): Programming device 1 > Info (209018): Device 1 silicon ID is 0x18 > Info (209011): Successfully performed operation(s) > Info (209061): Ended Programmer operation at Fri Aug 22 15:26:15 2014 > > which looked OK but no boot! Second from left front panel red led glows constantly but dim. > > Somewhere I noticed (post by Franz Hegener) that I should have selected EPC 128? My device (in the Quartus II 32 bit Programmer window shows Device=EPCS16 as read from Quartus-II Programmer window and also shown in the document "Quartus-II Programmer and Byteblaster" by N9VV and KCXG v2.3 dated 04/23/13. Is this my error? > > Any ideas to try next?? > > Thanks, > Larry W0AY > > Note for record: > 1. Version 12 of the Quartus II Programmer matches the "Quartus-II Programmer and Byteblaster" instructions (noted above) but the current version V12 does not. Obtain V12 here: https://www.altera.com/download/sw/dnl-sw-index.jsp# > > 2. Win7 refused to load the drivers provided by Altera in V14. I used the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From k5so at valornet.com Fri Aug 22 10:34:54 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Fri, 22 Aug 2014 11:34:54 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: <6CDCF9A3-A76E-4203-8939-984BA727DED3@valornet.com> Larry, One further comment, when loading an ?output_file.pof? into your Angelia it will power up with whatever firmware version number was used when the ?output_file.pof? was created. Therefore, after recovering using the blaster cable you will still need to update the firmware version to v4.1. If v4.1 happened to be used in creating the ?output_file.pof? then you do not need to update to v4.1 as it will already be loaded as part of the ?output_file.pof?. If you?re reluctant to try the update the Angelia using the HPSDRProgrammer the I?d suggest using the HPSDR Bootloader program instead, as it seems to be more robust (using a jumper on J17 during the update operation with HPSDR Bootloader, of course). The program you?d load using the HPSDR Bootloader is the same as you?d use with the HPSDR Programmer; namely, ?Angelia_v4.1.rbf?. 73, Joe K5SO From w5wc at windstream.net Fri Aug 22 10:43:04 2014 From: w5wc at windstream.net (Doug Wigley) Date: Fri, 22 Aug 2014 12:43:04 -0500 Subject: [hpsdr] PowerSDR/OpenHPSDR mRX PS v3.2.18 released Message-ID: <005601cfbe30$877604c0$96620e40$@net> All, PowerSDR/OpenHPSDR mRX PS v3.2.18 has been released. This is primarly a maintenace release which has a few bug fixes and feature enhancements added. The noteworthy changes are: - PowerSDR will check the database version being used on startup. If the databse was written by an older version of PowerSDR you will receive a warning and a choice to reset the database at that time. - Diversity values for the Reference Source, Gain, and Phase are saved and restored by band. - Diversity can now be enabled/disabled with the Diversity Form opened. - The PTT Control port can now use the same port as the CAT Control. This release can be downloaded from the openhpsdr.org website. http://openhpsdr.org/download.php 73, Doug W5WC From jkelly at verizon.net Fri Aug 22 13:12:28 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 22 Aug 2014 16:12:28 -0400 Subject: [hpsdr] FS - Band-pass filter Message-ID: Assembled Band-pass filter (BPF for SDR HERMES, ANAN-10 or HF transceiver) Similar to: http://www.ebay.com/itm/Band-pass-filter-BPF-for-SDR-HERMES-ANAN-10-or-HF-transceiver-/251578249143? $175. shipped CONUS. Jeff K2SDR -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkelly at verizon.net Fri Aug 22 14:22:37 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 22 Aug 2014 17:22:37 -0400 Subject: [hpsdr] FS - Band-pass filter In-Reply-To: References: Message-ID: <70FA5EC3B6604DCDB8E4102C084BD771@JeffPC> SOLD. Jeff From: Jeff Kelly Sent: Friday, August 22, 2014 16:12 To: hpsdr at openhpsdr.org Subject: [hpsdr] FS - Band-pass filter ***** High Performance Software Defined Radio Discussion List ***** -------------------------------------------------------------------------------- Assembled Band-pass filter (BPF for SDR HERMES, ANAN-10 or HF transceiver) Similar to: http://www.ebay.com/itm/Band-pass-filter-BPF-for-SDR-HERMES-ANAN-10-or-HF-transceiver-/251578249143? $175. shipped CONUS. Jeff K2SDR -------------------------------------------------------------------------------- _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From leskep at skymesh.com.au Fri Aug 22 16:12:40 2014 From: leskep at skymesh.com.au (Les Keppie) Date: Sat, 23 Aug 2014 09:12:40 +1000 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: <53F772A5.9050001@foxgulch.com> References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: Hi All I have experienced a similar situation regarding v4.1 whilst trying to revert to v4.0 After upgrading to v4.1 when it became available I only had it running for a short period when I was experiencing distorted audio - checked all bands same result - decided to revert to v4.0 firmware Using Programmer old file was reported as deleted but no perecntage values appeared when uploading the new file and the process never did complete I then switched to the Bootloader and again tried load v4.0 firmware - same result as using the Programmer This happened the day before I was due to go on 2 weeks holiday so just left everything as was On returning I thought about it for a while and decided to try the Bootloader and was able to upgrade to v4.1 and no distorted audio problems - have been running it now for some 4 days without any problems Just thought I would put this out for information Regards Les VK2DSG On Sat, 23 Aug 2014 02:41:09 +1000, Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Attempted to upgrade the firmware in my 100D using > HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when > I attempted to write 4.1 rbf, all operations stopped. Now it won't > boot. (J17 jumper on or off, doesn't help) > > So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and fired > off the Altera Quartus Programmer v12 build 177 11/7/2012 which > responded after I clicked Start as follows: > > Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 2014 > Info (209018): Device 1 silicon ID is 0x18 > Info (209044): Erasing ASP configuration device(s) > Info (209024): Programming device 1 > Info (209018): Device 1 silicon ID is 0x18 > Info (209011): Successfully performed operation(s) > Info (209061): Ended Programmer operation at Fri Aug 22 15:26:15 2014 > > which looked OK but no boot! Second from left front panel red led > glows constantly but dim. > > Somewhere I noticed (post by Franz Hegener) that I should have > selected EPC 128? My device (in the Quartus II 32 bit Programmer > window shows Device=EPCS16 as read from Quartus-II Programmer window and > also shown in the document "Quartus-II Programmer and Byteblaster" by > N9VV and KCXG v2.3 dated 04/23/13. Is this my error? > > Any ideas to try next?? > > Thanks, > Larry W0AY > > Note for record: > 1. Version 12 of the Quartus II Programmer matches the "Quartus-II > Programmer and Byteblaster" instructions (noted above) but the current > version V12 does not. Obtain V12 here: > https://www.altera.com/download/sw/dnl-sw-index.jsp# > > 2. Win7 refused to load the drivers provided by Altera in V14. I used > the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Using Opera's mail client: http://www.opera.com/mail/ From k5so at valornet.com Fri Aug 22 18:07:18 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Fri, 22 Aug 2014 19:07:18 -0600 Subject: [hpsdr] Angelia_v4.2 firmware release Message-ID: All, Angelia_v4.2 firmware is available for download from http://k5so.com/HPSDR_downloads.html This version of firmware slightly modifies the timing of v4.1 to make the design more robust with respect to running on many different Angelia boards. A few people have reported problems with v4.1 where one or more features became inoperable after 30 minutes or so of operation (e.g., CW sidetone simply stopping, etc). Most Angelia boards had no problem with v4.1 apparently but a few did. This v4.2 appears to have fixed those problems and appears to work fine on other Angelia boards too. I don?t know if the recently reported trouble experienced by a few people using HPSDR Programmer to update firmware in Angelia will be helped by this new firmware but it could, perhaps. In any case, should you run into trouble using HPSDR Programmer in the normal manner you should be able to use the HPSDR Bootloader program to recover. For those who wish to use the "brute force" method of completely reloading the Angelia EEPROM (including the bootloader code) by using a blaster cable with the Quartus II Programmer, I have created a new ?output_file.pof? file that includes both Angelia_v4.2 image and the bootloader code in it and I have included it in the zipped Angelia_v4.2 download folder. Using this ?output_file.pof? file will relieve you of the task of updating to v4.2 after loading the bootloader code, which you would need to do if you use an earlier version of ?output_file.pof? in your blaster cable process. Please keep in mind that you should not need to use a blaster cable to recover from a failed attempt to update firmware using HPSDR Programmer; recovery using HPSDR Bootloader (with J17 jumper in place, of course) should work for you in those (hopefully relatively rare!) cases. I included this new ?output_file.pof" file in the download folder only as a ?peace of mind? item and courtesy for those who like to use their blaster cables, hihi. 73, Joe K5SO From mlalonde at alphatronique.com Fri Aug 22 19:31:43 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Fri, 22 Aug 2014 22:31:43 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F7FD0F.6020301@alphatronique.com> Hi guess some one already work on a ADC /DAC Board that go on the expansion connector of the DEV kit ? seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA as Glue logic.. that may remove the LAN / PHY from equation and permit made nice self contained platform ;-) if no one yet ,i may willing to help work on this ,i was a senior PCB designer whit some design backgrond .. Best 73! Marc VE2OLM On 20/08/2014 3:31 AM, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From aa8k73 at gmail.com Fri Aug 22 19:43:52 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 22 Aug 2014 22:43:52 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/23 Message-ID: <53F7FFE8.3030108@gmail.com> The 23/Aug TeamSpeak mp3 (63 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3512 > or < http://www.hamsdr.com/dnld.aspx > Only silence truncation editing was done on this recording. Session text follows <20:35:08> *** You are now talking in channel: "OpenHPSDR" <21:06:29> "Bill - KD5TFD": needs better networking? <21:08:21> "Bill - KD5TFD": If he's an expert it's only an afternoon project <21:13:48> "Ken N9VV": CWSkimmer <21:18:15> "Warren - NR0V": < https://dl.dropboxusercontent.com/u/9282924/hpsdr/xcmaster.JPG > <21:28:04> "Ken N9VV": "Bonding" <21:28:32> "Bill - KD5TFD": 2 lane highway <21:28:56> "Jae - K5JAE": pci-e? <21:31:32> "Bill - KD5TFD": You mean I can't do 30 Mhz wide transmit? <21:32:20> "Bill - KD5TFD": light weight gui .. now that's an oxymoron <21:33:26> "Ken N9VV": Lightweight GUI = Android glSDR or HPSDR with Qt server doing all the work(?) <21:36:02> "Jae - K5JAE": FreeDV? <21:46:03> "Ken N9VV": K5SO released Angelia 4.2 tonight --- < http://k5so.com/Angelia_v4.2.zip > <21:47:46> "Bill - KD5TFD": anyone have a vnc server running on their Jetson? <21:51:50> "Jae - K5JAE": software is soft... hardware is hard :) <21:52:45> "Ken N9VV": SDRMAX = circa: 2004 according to N8VB Blog <21:55:56> "Rob - VE3EW": < http://www.iwavesystems.com/product/cpu-modules/cyclone-v-soc-qseven-som/altera-cyclone-v-soc-qseven-module.html > <21:57:12> "Bill - KD5TFD": awful lot of expertise in building a full blown computer board <21:57:43> "Bill - KD5TFD": an dcan you get it debugged in our lifetimes ... <22:05:12> "Bill - KD5TFD": dwim <22:05:27> "Bill - KD5TFD": dwim eax, edx <22:05:30> "Jae - K5JAE": is that called c#? From phil at pharman.org Fri Aug 22 20:31:13 2014 From: phil at pharman.org (Phil Harman) Date: Sat, 23 Aug 2014 11:31:13 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F7FD0F.6020301@alphatronique.com> References: <53F7FD0F.6020301@alphatronique.com> Message-ID: <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Hi Marc, Thanks for your email. We still have a way to go with fully proving the DFC idea but so far its looking good. We actually had this discussion a few minutes ago during the weekly Teamspeak session. Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. If such a PCB design is of interest to you then please lets discuss further. 73 Phil....VK6PH -----Original Message----- From: Marc Lalonde Sent: Saturday, August 23, 2014 10:31 AM To: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Hi guess some one already work on a ADC /DAC Board that go on the expansion connector of the DEV kit ? seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA as Glue logic.. that may remove the LAN / PHY from equation and permit made nice self contained platform ;-) if no one yet ,i may willing to help work on this ,i was a senior PCB designer whit some design backgrond .. Best 73! Marc VE2OLM On 20/08/2014 3:31 AM, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to > openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From rick at teksharp.com Sat Aug 23 06:20:21 2014 From: rick at teksharp.com (Rick Fletcher) Date: Sat, 23 Aug 2014 07:20:21 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: <00ef01cfbed5$0b5c8d00$2215a700$@teksharp.com> I'm still running V3.5 and have experienced distorted audio twice. Both times, I was able to restore normal operation by terminating PowerSDR and launching a new instance of it. 73, Rick, W7YP -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Les Keppie Sent: Friday, August 22, 2014 5:13 PM To: larry at foxgulch.com; hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable ***** High Performance Software Defined Radio Discussion List ***** Hi All I have experienced a similar situation regarding v4.1 whilst trying to revert to v4.0 After upgrading to v4.1 when it became available I only had it running for a short period when I was experiencing distorted audio - checked all bands same result - decided to revert to v4.0 firmware Using Programmer old file was reported as deleted but no perecntage values appeared when uploading the new file and the process never did complete I then switched to the Bootloader and again tried load v4.0 firmware - same result as using the Programmer This happened the day before I was due to go on 2 weeks holiday so just left everything as was On returning I thought about it for a while and decided to try the Bootloader and was able to upgrade to v4.1 and no distorted audio problems - have been running it now for some 4 days without any problems Just thought I would put this out for information Regards Les VK2DSG On Sat, 23 Aug 2014 02:41:09 +1000, Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Attempted to upgrade the firmware in my 100D using > HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when > I attempted to write 4.1 rbf, all operations stopped. Now it won't > boot. (J17 jumper on or off, doesn't help) > > So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and > fired off the Altera Quartus Programmer v12 build 177 11/7/2012 which > responded after I clicked Start as follows: > > Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 > 2014 Info (209018): Device 1 silicon ID is 0x18 Info (209044): Erasing > ASP configuration device(s) Info (209024): Programming device 1 Info > (209018): Device 1 silicon ID is 0x18 Info (209011): Successfully > performed operation(s) Info (209061): Ended Programmer operation at > Fri Aug 22 15:26:15 2014 > > which looked OK but no boot! Second from left front panel red led > glows constantly but dim. > > Somewhere I noticed (post by Franz Hegener) that I should have > selected EPC 128? My device (in the Quartus II 32 bit Programmer > window shows Device=EPCS16 as read from Quartus-II Programmer window > and also shown in the document "Quartus-II Programmer and Byteblaster" by > N9VV and KCXG v2.3 dated 04/23/13. Is this my error? > > Any ideas to try next?? > > Thanks, > Larry W0AY > > Note for record: > 1. Version 12 of the Quartus II Programmer matches the "Quartus-II > Programmer and Byteblaster" instructions (noted above) but the current > version V12 does not. Obtain V12 here: > https://www.altera.com/download/sw/dnl-sw-index.jsp# > > 2. Win7 refused to load the drivers provided by Altera in V14. I used > the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Using Opera's mail client: http://www.opera.com/mail/ _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From mlalonde at alphatronique.com Sat Aug 23 06:42:14 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Sat, 23 Aug 2014 09:42:14 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <53F89A36.4070905@alphatronique.com> Hi Phil, After some quick reading it seems that ePCI bus is Point to Point (no need for southBridge) It may sure be a good idea and let option to upgrade the Nvidia card later as tech advance. My work schedule have a bit more room on September so if there is need I will be happy to jump in. Best 73! On 22/08/2014 11:31 PM, Phil Harman wrote: > Hi Marc, > > Thanks for your email. > > We still have a way to go with fully proving the DFC idea but so far > its looking good. > > We actually had this discussion a few minutes ago during the weekly > Teamspeak session. > > Whilst the GPIO is one solution our concern is that the Jetson board > is not going to be a production item for Nvidia. There is no > guarantee that what board replaces it, be it 64 bit Jeston or > something completely different, may not have the same GIPO port. > > What does look viable is a board using miniPCIe since there is a > good possibility that future SBCs will carry this interface. > > What was suggested was a miniPCIe board with an Altera Cyclone V FPGA > (since this has PCIe implement in hardware on the chip) plus an ADC, > DAC and I/O. The I/O could include an interface to the Alex board so > we can use that rather than reproduce that hardware. > > With an FPGA on the board we have many options from DFC down to > porting the existing DDC/DUC code, which is all ready proven to work. > > If such a PCB design is of interest to you then please lets discuss > further. > > 73 Phil....VK6PH > > > > > -----Original Message----- From: Marc Lalonde > Sent: Saturday, August 23, 2014 10:31 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > guess some one already work on a ADC /DAC Board that go on the expansion > connector of the DEV kit ? > seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA > as Glue logic.. > > that may remove the LAN / PHY from equation and permit made nice self > contained platform ;-) > > if no one yet ,i may willing to help work on this ,i was a senior PCB > designer whit some design backgrond .. > > Best 73! > Marc VE2OLM > > On 20/08/2014 3:31 AM, Phil Harman wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> I'm delighted to be able to report that we have been able to develop, to >> proof-of-concept stage, a new SDR architecture. >> >> Current SDRs use the software equivalent of zero IF techniques, i.e. >> DDC, >> in order to provide (multiple) receivers. Whist this is quite >> effective, >> much of the initial DSP work is done using FPGAs, or a combination of >> FPGA >> plus dedicated DSP chips and microprocessors, rather than totally within >> the PC. >> >> As more complex features are added, the size and complexity of the FPGA >> and DSP code increases. The skills to write, debug and maintain this >> code >> is only available via a small percentage of software engineers, or >> enthusiasts, in comparison to those able to write code for PC based >> hardware. >> >> In order to open the SDR world to those with PC software skills we >> are in >> the process of developing a new SDR architecture. >> >> This architecture digitises the entire 0 to 30MHz radio spectrum in real >> time and passes the 'raw' samples directly to an associated computer. >> >> This computer then calculates the FFT of the raw samples and >> subsequently >> processes the result as the user requires. >> >> This is not a totally new concept since both the cuSDR and KISS Konsole >> software uses raw ADC samples to provide the wideband bandscope >> displays. >> >> However, for this requirement the FFT only needs to be done at the >> bandscope update rate of a few 10's of times per second, which hardly >> taxes a modern PC at all. >> >> The new concept requires that we take the FFT of all samples in >> real-time. >> >> This has been possible in the past - if you had access to a Cray super >> computer! >> >> Well now we do have access to very low cost computers that provide the >> processing power we need. One example of this is the new Nvidia Jetson >> TK1 single board computer. At a cost of $192 this board contains >> four ARM >> CPUs plus 192 CUDA processors. >> >> More details of this remarkable board can be found here: >> >> https://developer.nvidia.com/jetson-tk1 >> >> Since the CUDA cores can process data in parallel, we can use these to >> perform the high speed FFT. >> >> John, G0ORX, has written preliminary code for the Jetson board and has >> confirmed that it has the necessary performance we require. >> >> The test environment consisted of a Jetson board connected via Gigabit >> Ethernet to an Angelia board. A special version of FPGA code was >> written >> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps >> to the >> Jetson board. >> >> We used raw Ethernet frames over the Gigabit link, in order to maximise >> the link bandwidth, since we require a sustained 983Mbps transfer rate. >> >> Whilst it's still early days, and there is much more to be done, this >> critical early success does indicate that this new architecture has a >> very >> promising future. >> >> The Jetson board is taking the role of an 'SDR Server' which I have >> written about in the past. >> >> In which case what benefits does this new architecture provide to >> openHPSR? >> >> 1. The FPGA code is greatly simplified, is easier to write and maintain, >> and hence uses a small percentage of the space available with a >> subsequent >> reduction in power consumption. >> >> 2. The protocol between the SDR hardware and the SDR Server is greatly >> simplified since the SDR hardware only has to connect to a single, >> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >> required. The SDR Server simply needs to know the MAC address of the >> SDR >> hardware in order to communicate. It should be possible for a single >> SDR >> hardware board to feed multiple SDR Servers, but that's something for >> the >> future. >> >> 3. Virtually all the signal processing is undertaken on the associated >> single board computer (SBC) or (suitable) PC. If sufficient processing >> power is available then the GUI can run on the same SBC. >> Alternatively the >> user's normal PC (which does not require to be high performance since it >> does not do any significant digital signal processing) or a Tablet, cell >> phone etc could be used. >> >> 4. Many more users have the necessary skills and experience to support, >> maintain and further develop the code. New features are added to the SDR >> Server code rather than the FPGA code. >> >> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >> FPGA >> and/or power supply restrictions may have limited adding new features. >> >> 6. Future hardware upgrades will be to the associated SBC where >> faster and >> lower cost options can be expected. Nvidia have already indicated >> that a >> 64 bit board will be available in the near future. >> >> 7. Remote access to an SDR via the Internet will enable multiple >> users to >> share the SDR with each selecting their desired frequency, bandwidth and >> mode. >> >> There are other potential benefits relating to simpler and lower cost >> SDR >> hardware, but that is for the future. >> >> For want of a name we are calling this new architecture 'Direct Fourier >> Conversion' (DFC). >> >> For those that are already experimenting with the Jetson board we do >> intend to release the DFC FPGA code for both Angelia and Hermes >> boards and >> I will advise when, and where, this is available. >> >> John's code is presently not available, so please don't pester him, >> but as >> soon as it reaches Beta stage it will be released. >> >> Please join me in congratulating John on this exciting development. >> >> 73 Phil....VK6PH >> >> >> >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > From sbdick at optonline.net Sat Aug 23 08:13:24 2014 From: sbdick at optonline.net (Steven B. Dick) Date: Sat, 23 Aug 2014 11:13:24 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: Phil, as you indicated, The skills to write, debug and maintain FPGA code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. This has been a major problem in industry for years, as the cost per "line of code" is much higher for firmware vs. software for code development and maintenance, on the order of a factor of perhaps 10 to 1 for FPGA firmware vs. software written in a high order language. Note that tools such as MATLAB can be used to develop FPGA code directly rather than hand coding verilog or VHDL code but are not low cost tools. Another approach to consider is the newly emerging FPGA vendor support of high order "graphics" programming languages for their latest "System on a chip" FPGAs. Both Altera and Xilinx are now beginning to support the OpenCL programming language for their FPGAs using their latest toolsets. OpenCL is not proprietary vs. CUDA which is tied in with NVIDIA. CUDA is more mature and has a more extensive set of available libraries and a larger user community however. Although programming with OpenCL on an FPGA vs. a graphics chip using multiple graphics processing engines requires different programming approaches to take best advantages of the underlying hardware resources, this may be a way to program for "System on a chip" FPGAs, strictly in software though maintining a mix of hardware and software resources, including multiple ARM processors. Regards. "Digital Steve", K1RF -----Original Message----- All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. *********************** From rcrewson at cinci.rr.com Sat Aug 23 09:26:41 2014 From: rcrewson at cinci.rr.com (Rob Crewson) Date: Sat, 23 Aug 2014 12:26:41 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> Hi Steve, I have been looking OpenCL for a couple of months by taking some online courses. Of note is that NVidia also belongs and supports the consortium. Unfortunately in the last one of the series (just watched it today ), it mentions that a fully licensed of QuartusII is needed in order to actually get compiled code generated and loaded on a FPGA. I did not check the development board costs at that point but they are licensed for a fee as well. 73, Rob Crewson - VE3EW -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Steven B. Dick Sent: Saturday, August 23, 2014 11:13 AM To: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Phil, as you indicated, The skills to write, debug and maintain FPGA code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. This has been a major problem in industry for years, as the cost per "line of code" is much higher for firmware vs. software for code development and maintenance, on the order of a factor of perhaps 10 to 1 for FPGA firmware vs. software written in a high order language. Note that tools such as MATLAB can be used to develop FPGA code directly rather than hand coding verilog or VHDL code but are not low cost tools. Another approach to consider is the newly emerging FPGA vendor support of high order "graphics" programming languages for their latest "System on a chip" FPGAs. Both Altera and Xilinx are now beginning to support the OpenCL programming language for their FPGAs using their latest toolsets. OpenCL is not proprietary vs. CUDA which is tied in with NVIDIA. CUDA is more mature and has a more extensive set of available libraries and a larger user community however. Although programming with OpenCL on an FPGA vs. a graphics chip using multiple graphics processing engines requires different programming approaches to take best advantages of the underlying hardware resources, this may be a way to program for "System on a chip" FPGAs, strictly in software though maintining a mix of hardware and software resources, including multiple ARM processors. Regards. "Digital Steve", K1RF -----Original Message----- All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. *********************** _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From k5so at valornet.com Sat Aug 23 11:06:14 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sat, 23 Aug 2014 12:06:14 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> Message-ID: <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> A personal comment regarding FPGA programming and programming in general: The view that writing and maintaining FPGA code is beyond the capability of most of us has been blown completely out of proportion to reality! That view is simply incorrect. Indeed, I?m a good example of the point, I think. As many of you know, I am certainly not a professional programmer and, in fact, I have had no serious programming experience at all in any computer language in my life. Since joining the HPSDR community a few years ago I have managed to muddle my way along in learning how to successfully write both FPGA code and PowerSDR (C# and C) code and have discovered that it simply isn?t that hard to do. I readily admit that my code isn?t ?elegant? in the purist view but it works (sometimes anyway, hihi). The point I?m trying to make is that you only have to be willing to learn something new, that?s all, and not be too timid to give it a try to ultimately become successful in doing ANY of the programming we do. Indeed, it turns out that even the often-viewed-as-no-man?s-land of timing FPGA designs is actually completely accessible to non-professionals such as we are and, in fact, the task is easily within the grasp of the average experimenter. Further, we have always used and are still using free versions of Quartus II to create FPGA designs and load the FPGAs without problem. You don?t have to have the fully licensed Quartus II versions to do anything we wish to do with these FPGAs. Counter to what one might assume from the recent discussions, any of us can do FPGA programming with the free tools we have available from Altera if you only care to put the effort into learning how to do it. It just isn?t that hard! I?m certainly no expert in any of this stuff and would never claim to be but you don?t have to be an expert to be able to learn to work with these tools and be able to make meaningful contributions. There is no reason at all that only a small percentage of our group can do FPGA programming! The truth is that anyone can do it if you set your mind to do it. 73, Joe K5SO On Aug 23, 2014, at 10:26 AM, Rob Crewson wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Steve, > > I have been looking OpenCL for a couple of months by taking some online > courses. > Of note is that NVidia also belongs and supports the consortium. > > Unfortunately in the last one of the series (just watched it today ), it > mentions that a fully licensed of QuartusII > is needed in order to actually get compiled code generated and loaded on > a FPGA. > > I did not check the development board costs at that point but they are > licensed for a fee as well. > > 73, > > Rob Crewson - VE3EW > > > > -----Original Message----- > From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Steven > B. Dick > Sent: Saturday, August 23, 2014 11:13 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > ***** High Performance Software Defined Radio Discussion List ***** > > Phil, as you indicated, The skills to write, debug and maintain FPGA code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. This has been a major problem in industry for years, as the cost > per "line of code" is much higher for firmware vs. software for code > development and maintenance, on the order of a factor of perhaps 10 to 1 for > FPGA firmware vs. software written in a high order language. Note that > tools such as MATLAB can be used to develop FPGA code directly rather than > hand coding verilog or VHDL code but are not low cost tools. > > Another approach to consider is the newly emerging FPGA vendor support of > high order "graphics" programming languages for their latest "System on a > chip" FPGAs. Both Altera and Xilinx are now beginning to support the OpenCL > programming language for their FPGAs using their latest toolsets. OpenCL is > not proprietary vs. CUDA which is tied in with NVIDIA. CUDA is more mature > and has a more extensive set of available libraries and a larger user > community however. Although programming with OpenCL on an FPGA vs. a > graphics chip using multiple graphics processing engines requires different > programming approaches to take best advantages of the underlying hardware > resources, this may be a way to program for "System on a chip" FPGAs, > strictly in software though maintining a mix of hardware and software > resources, including multiple ARM processors. > > Regards. "Digital Steve", K1RF > > -----Original Message----- > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within the > PC. > > As more complex features are added, the size and complexity of the FPGA and > DSP code increases. The skills to write, debug and maintain this code is > only available via a small percentage of software engineers, or enthusiasts, > in comparison to those able to write code for PC based hardware. > > *********************** > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From sbdick at optonline.net Sat Aug 23 12:10:10 2014 From: sbdick at optonline.net (Steven B. Dick) Date: Sat, 23 Aug 2014 15:10:10 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> Message-ID: <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with a desire to learn and my hat is off to you for taking it upon yourself to learn both firmware and software programming. That was not the point I was trying to make. In my previous life, I was a digital design manager. FPGA code designed by experienced senior FPGA designers took a lot more time to develop (even worse to maintain) compared to software written by experienced software developers which ran on general purpose compute nodes. For many years, FPGA designs had an important role to play where special functions just could not be done in general purpose processors or even DSP processors with comparable performance, but one willingly paid for it in reaping the benefits of high performance and/or greatly reduced hardware footprint. But the processing landscape is changing nowadays with very low cost processing platforms based on multiple node graphics engines coupled with high order language support with DSP libraries. Use of these platforms is starting to result in huge performance capabilities in a low cost rapid development environment if these platforms can be readily used for particular applications including the FFT function. Regards, "Digital Steve", K1RF -----Original Message----- From: Joe Martin K5SO [mailto:k5so at valornet.com] Sent: Saturday, August 23, 2014 2:06 PM To: Rob Crewson Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development A personal comment regarding FPGA programming and programming in general: The view that writing and maintaining FPGA code is beyond the capability of most of us has been blown completely out of proportion to reality! That view is simply incorrect. Indeed, I'm a good example of the point, I think. From k5so at valornet.com Sat Aug 23 12:23:43 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sat, 23 Aug 2014 13:23:43 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> Message-ID: <260DD696-CE58-4F14-A24E-55B5FFCCDC3F@valornet.com> There are many such sources for information. To learn the basics of the Verilog language, which is what we use to write the FPGA code designs, Kirk Weedman KD7IRS some years ago kindly put together a beginners course tailored to the HPSDR project. The course is available for download on the HPSDR webpage below: http://verilog.openhpsdr.org However, in my experience the absolute best way to learn how to do this is by downloading Quartus II, installing it on your computer, and using it to examine an existing HPSDR firmware design. By examing an actual firmware design that we are using today you can see how the various tasks are accomplished in the code. We try to comment the code as much as is practical in order to help us remember what each section does but also to help newcomers understand what the code section is doing. You can spend lots of unnecessary time attending/viewing classes which will be giving you much info regarding Verilog syntax, etc, but you can also get the idea very quickly by examining an actual firmware design by using the Quartus II editor. In addition, you?ll immediately be learning how to use the Quartus II tool. In short, my view that the absolute best way to learn is to get your feet wet immediately with the tool that you will be using; i.e., Quartus II, to examine an existing firmware design. The primary issue to understand about FPGA code, in my view, is to realize from the start that each little section of code within the firmware design runs in parallel with every other section. That is, the code execution is not ?event driven? as it is in Windows programming nor is it strictly running lines of code sequentially as in some languages (except within each section of code in the firmare design). Because of this it is actually easy to take one little section of code and examine it carefully to see what it is doing, how it is doing it, and what syntax is used to accomplish it. After you feel you understand a portion of it then you can make small changes to it, compile it, and see what effect your change(s) have on the performance of the firmware design by actually loading it into your HPSDR rigs? FPGA. Plus you immediately gain experience in how to do all that. Sure, you?ll make mistakes! But be assured that anything you do is recoverable; you can?t hurt the FPGA by misprogramming it. 73, Joe K5SO On Aug 23, 2014, at 12:46 PM, Neal Campbell wrote: > Are there any good beginner courses on the internet? > > 73 > > Neal Campbell > Abroham Neal LLC > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Sat Aug 23 12:46:38 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sat, 23 Aug 2014 13:46:38 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> Message-ID: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> Hi Steve, RR, understood. I appreciate your point. But as you noted, the landscape has changed and is continually changing such that the world of FPGA programming is not limited to those senior FPGA programmers anymore. Granted, who knows if or how long FPGAs will be important, but for our project right now and for the forseeable future they are central to our designs. Therefore, it should be understood by all that the domain of FPGA programming is certainly not now limited to ?senior FPGA programmers?. We can successfully do such programming ourselves if we want to do it. 73, Joe K5SO On Aug 23, 2014, at 1:10 PM, Steven B. Dick wrote: > Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with > a desire to learn and my hat is off to you for taking it upon yourself to > learn both firmware and software programming. That was not the point I was > trying to make. In my previous life, I was a digital design manager. FPGA > code designed by experienced senior FPGA designers took a lot more time to > develop (even worse to maintain) compared to software written by experienced > software developers which ran on general purpose compute nodes. For many > years, FPGA designs had an important role to play where special functions > just could not be done in general purpose processors or even DSP processors > with comparable performance, but one willingly paid for it in reaping the > benefits of high performance and/or greatly reduced hardware footprint. But > the processing landscape is changing nowadays with very low cost processing > platforms based on multiple node graphics engines coupled with high order > language support with DSP libraries. Use of these platforms is starting to > result in huge performance capabilities in a low cost rapid development > environment if these platforms can be readily used for particular > applications including the FFT function. > > Regards, > "Digital Steve", K1RF > > -----Original Message----- > From: Joe Martin K5SO [mailto:k5so at valornet.com] > Sent: Saturday, August 23, 2014 2:06 PM > To: Rob Crewson > Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > A personal comment regarding FPGA programming and programming in general: > > The view that writing and maintaining FPGA code is beyond the capability of > most of us has been blown completely out of proportion to reality! That > view is simply incorrect. > > Indeed, I'm a good example of the point, I think. > From n9vv at wowway.com Sat Aug 23 16:13:32 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Sat, 23 Aug 2014 18:13:32 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> Message-ID: <53F9201C.8050306@wowway.com> P.S. I think Joe has a 4 digit IQ and he is just too polite to tell us!! 73 de Ken N9VV On 8/23/2014 2:46 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Steve, > > RR, understood. I appreciate your point. > > But as you noted, the landscape has changed and is continually changing such that the world of FPGA programming is not limited to those senior FPGA programmers anymore. Granted, who knows if or how long FPGAs will be important, but for our project right now and for the forseeable future they are central to our designs. Therefore, it should be understood by all that the domain of FPGA programming is certainly not now limited to ?senior FPGA programmers?. We can successfully do such programming ourselves if we want to do it. > > 73, Joe K5SO > > On Aug 23, 2014, at 1:10 PM, Steven B. Dick wrote: > >> Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with >> a desire to learn and my hat is off to you for taking it upon yourself to >> learn both firmware and software programming. That was not the point I was >> trying to make. In my previous life, I was a digital design manager. FPGA >> code designed by experienced senior FPGA designers took a lot more time to >> develop (even worse to maintain) compared to software written by experienced >> software developers which ran on general purpose compute nodes. For many >> years, FPGA designs had an important role to play where special functions >> just could not be done in general purpose processors or even DSP processors >> with comparable performance, but one willingly paid for it in reaping the >> benefits of high performance and/or greatly reduced hardware footprint. But >> the processing landscape is changing nowadays with very low cost processing >> platforms based on multiple node graphics engines coupled with high order >> language support with DSP libraries. Use of these platforms is starting to >> result in huge performance capabilities in a low cost rapid development >> environment if these platforms can be readily used for particular >> applications including the FFT function. >> >> Regards, >> "Digital Steve", K1RF >> >> -----Original Message----- >> From: Joe Martin K5SO [mailto:k5so at valornet.com] >> Sent: Saturday, August 23, 2014 2:06 PM >> To: Rob Crewson >> Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org >> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >> >> A personal comment regarding FPGA programming and programming in general: >> >> The view that writing and maintaining FPGA code is beyond the capability of >> most of us has been blown completely out of proportion to reality! That >> view is simply incorrect. >> >> Indeed, I'm a good example of the point, I think. >> > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From w4yn at earthlink.net Sat Aug 23 16:18:39 2014 From: w4yn at earthlink.net (Tim ORourke) Date: Sat, 23 Aug 2014 19:18:39 -0400 (GMT-04:00) Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <11504088.1408835920124.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> I think all the guys doing this are 4 digit geeks! And that's a great attribute IMHO! Tim Tim O\Rourke W4YN at ARRL.Net Low Power Amateur Radio Rocks Member of Flying Pigs,ARCI,GQRP,RSGB,ARRL Life Member R/C Pilot (sort of) NRA Life Member NRA Certified Rifle, Pistol, Black Powder Instructor, Range Officer -----Original Message----- >From: "Ken N9VV (Win-7/64)" >Sent: Aug 23, 2014 7:13 PM >To: hpsdr at lists.openhpsdr.org >Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > >***** High Performance Software Defined Radio Discussion List ***** > >P.S. I think Joe has a 4 digit IQ and he is just too polite to tell us!! > >73 de Ken N9VV > >On 8/23/2014 2:46 PM, Joe Martin K5SO wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Steve, >> >> RR, understood. I appreciate your point. >> >> But as you noted, the landscape has changed and is continually changing such that the world of FPGA programming is not limited to those senior FPGA programmers anymore. Granted, who knows if or how long FPGAs will be important, but for our project right now and for the forseeable future they are central to our designs. Therefore, it should be understood by all that the domain of FPGA programming is certainly not now limited to ?senior FPGA programmers?. We can successfully do such programming ourselves if we want to do it. >> >> 73, Joe K5SO >> >> On Aug 23, 2014, at 1:10 PM, Steven B. Dick wrote: >> >>> Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with >>> a desire to learn and my hat is off to you for taking it upon yourself to >>> learn both firmware and software programming. That was not the point I was >>> trying to make. In my previous life, I was a digital design manager. FPGA >>> code designed by experienced senior FPGA designers took a lot more time to >>> develop (even worse to maintain) compared to software written by experienced >>> software developers which ran on general purpose compute nodes. For many >>> years, FPGA designs had an important role to play where special functions >>> just could not be done in general purpose processors or even DSP processors >>> with comparable performance, but one willingly paid for it in reaping the >>> benefits of high performance and/or greatly reduced hardware footprint. But >>> the processing landscape is changing nowadays with very low cost processing >>> platforms based on multiple node graphics engines coupled with high order >>> language support with DSP libraries. Use of these platforms is starting to >>> result in huge performance capabilities in a low cost rapid development >>> environment if these platforms can be readily used for particular >>> applications including the FFT function. >>> >>> Regards, >>> "Digital Steve", K1RF >>> >>> -----Original Message----- >>> From: Joe Martin K5SO [mailto:k5so at valornet.com] >>> Sent: Saturday, August 23, 2014 2:06 PM >>> To: Rob Crewson >>> Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org >>> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >>> >>> A personal comment regarding FPGA programming and programming in general: >>> >>> The view that writing and maintaining FPGA code is beyond the capability of >>> most of us has been blown completely out of proportion to reality! That >>> view is simply incorrect. >>> >>> Indeed, I'm a good example of the point, I think. >>> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >_______________________________________________ >HPSDR Discussion List >To post msg: hpsdr at openhpsdr.org >Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >HPSDR web page: http://openhpsdr.org >Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From scotty at tonks.com Sat Aug 23 16:43:31 2014 From: scotty at tonks.com (Scott Cowling) Date: Sat, 23 Aug 2014 16:43:31 -0700 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <260DD696-CE58-4F14-A24E-55B5FFCCDC3F@valornet.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> <260DD696-CE58-4F14-A24E-55B5FFCCDC3F@valornet.com> Message-ID: <53F92723.8020105@tonks.com> I want to echo Joe's sentiments on FPGA development exactly. In many respects, getting started in FPGA programming is *easier* than jumping into C++ programming. When you download the tools, the environment is all set up for you. You do not need to try to figure out which toolset to use, where to get it, how to configure it, etc. There are many excellent references and tutorials available for learning Verilog. If you are already a hardware designer, it is even easier, since Verilog synthesis constructs generate hardware. You can start out with the simple constructs, then learn and use more "elegant" style as you go. The absolute best way to start is by reading, understanding and modifying existing code examples. The SDRstick BeRadio FPGA design is a good starting place. Look in svn.sdrstick.com under "sdrstick-release/beradio/beradio-firmware/source". This is a commented, stand-alone AM radio design in Verilog. You can even get hardware to run it on if you like, but it is not necessary; there is benefit to gain just by studying the sample code. There are small FPGA development kits for as little as $49 if you want to try your hand at writing a "Hello LED" program (the hardware equivalent of the beginning C programmer's "Hello World" program). The two main things to remember are: 1. don't be afraid to jump right in 2. take it slowly and *have fun* I have been programming FPGAs since the 1980s, and it is *still* fun! 73, Scotty WA2DFI On 2014-08-23 12:23, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > There are many such sources for information. To learn the basics of the > Verilog language, which is what we use to write the FPGA code designs, > Kirk Weedman KD7IRS some years ago kindly put together a beginners > course tailored to the HPSDR project. The course is available for > download on the HPSDR webpage below: > > http://verilog.openhpsdr.org > > However, in my experience the absolute best way to learn how to do this > is by downloading Quartus II, installing it on your computer, and using > it to examine an existing HPSDR firmware design. By examing an actual > firmware design that we are using today you can see how the various > tasks are accomplished in the code. We try to comment the code as much > as is practical in order to help us remember what each section does but > also to help newcomers understand what the code section is doing. > > You can spend lots of unnecessary time attending/viewing classes which > will be giving you much info regarding Verilog syntax, etc, but you can > also get the idea very quickly by examining an actual firmware design by > using the Quartus II editor. In addition, you?ll immediately be > learning how to use the Quartus II tool. In short, my view that the > absolute best way to learn is to get your feet wet immediately with the > tool that you will be using; i.e., Quartus II, to examine an existing > firmware design. > > The primary issue to understand about FPGA code, in my view, is to > realize from the start that each little section of code within the > firmware design runs in parallel with every other section. That is, the > code execution is not ?event driven? as it is in Windows programming nor > is it strictly running lines of code sequentially as in some languages > (except within each section of code in the firmare design). Because of > this it is actually easy to take one little section of code and examine > it carefully to see what it is doing, how it is doing it, and what > syntax is used to accomplish it. > > After you feel you understand a portion of it then you can make small > changes to it, compile it, and see what effect your change(s) have on > the performance of the firmware design by actually loading it into your > HPSDR rigs? FPGA. Plus you immediately gain experience in how to do all > that. Sure, you?ll make mistakes! But be assured that anything you do > is recoverable; you can?t hurt the FPGA by misprogramming it. > > 73, Joe K5SO > > On Aug 23, 2014, at 12:46 PM, Neal Campbell wrote: > >> Are there any good beginner courses on the internet? >> >> 73 >> >> Neal Campbell >> Abroham Neal LLC >> >> >> > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From brian13434 at yahoo.co.uk Sun Aug 24 05:38:15 2014 From: brian13434 at yahoo.co.uk (Brian D) Date: Sun, 24 Aug 2014 13:38:15 +0100 Subject: [hpsdr] Angelia_v4.2 firmware release In-Reply-To: References: Message-ID: Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > Angelia_v4.2 firmware is available for download from > > http://k5so.com/HPSDR_downloads.html > Is this suitable for use in the ANAN range of tranceivers or does it need to be changed by Abhi for the different filter frequencies? -- Brian D G3VGZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From k5so at valornet.com Sun Aug 24 06:30:01 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 24 Aug 2014 07:30:01 -0600 Subject: [hpsdr] Angelia_v4.2 firmware release In-Reply-To: References: Message-ID: Hi Brian, The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. The firmware uses correct switch-point frequencies for the Alex filter set, which is also the correct switch-point frequencies for the ANAN-series radios that have the correct windings on their filters. It is my understanding that later versions of the ANAN series radios use correct windings on their 10/12m filters so their switch points should be identical to those in Alex. Earlier versions of the ANAN series radios do not. The firmware ?patch? used initially by Abhi to correct the 10m low power output for some ANAN series radios is not the ideal method for correcting the issue of low power output on 10m on those earlier ANAN radios, as the issue is actually a hardware issue, not a firmware or software issue. If Abhi wishes to create a version of firmware that uses different switch points from Alex that?s his prerogative but you should be aware that the issue is not actually a firmware issue, it?s a hardware issue. The fact is that there should be only a single firmware version to use with each of the Hermes, Angelia, and Orion boards, respectively, regardless of whether the board are used in an ANAN-series configuration with the Apache Labs filters or in a stand alone configuration using Alex filters. The "correct fix? for ANAN radios that have the low power output issue on 10m is to rewind the filter toroids for the 10/12 m filters on those radios, not to patch the firmware or software to use switch points that are different from the Alex filter design. 73, Joe K5SO On Aug 24, 2014, at 6:38 AM, Brian D wrote: > Joe Martin K5SO wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> Angelia_v4.2 firmware is available for download from >> >> http://k5so.com/HPSDR_downloads.html >> > Is this suitable for use in the ANAN range of tranceivers or does it need to > be changed by Abhi for the different filter frequencies? > > -- > Brian D > G3VGZ > > --- > This email is free from viruses and malware because avast! Antivirus protection is active. > http://www.avast.com > From k5so at valornet.com Sun Aug 24 06:43:04 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 24 Aug 2014 07:43:04 -0600 Subject: [hpsdr] Angelia_v4.2 firmware release In-Reply-To: References: Message-ID: > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. Excuse me. A more accurate statement would?ve been: "The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience a lower maximum output power on 10m than you will if the windings are correct.? 73, Joe K5SO On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Brian, > > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. > > The firmware uses correct switch-point frequencies for the Alex filter set, which is also the correct switch-point frequencies for the ANAN-series radios that have the correct windings on their filters. It is my understanding that later versions of the ANAN series radios use correct windings on their 10/12m filters so their switch points should be identical to those in Alex. Earlier versions of the ANAN series radios do not. > > The firmware ?patch? used initially by Abhi to correct the 10m low power output for some ANAN series radios is not the ideal method for correcting the issue of low power output on 10m on those earlier ANAN radios, as the issue is actually a hardware issue, not a firmware or software issue. If Abhi wishes to create a version of firmware that uses different switch points from Alex that?s his prerogative but you should be aware that the issue is not actually a firmware issue, it?s a hardware issue. > > The fact is that there should be only a single firmware version to use with each of the Hermes, Angelia, and Orion boards, respectively, regardless of whether the board are used in an ANAN-series configuration with the Apache Labs filters or in a stand alone configuration using Alex filters. The "correct fix? for ANAN radios that have the low power output issue on 10m is to rewind the filter toroids for the 10/12 m filters on those radios, not to patch the firmware or software to use switch points that are different from the Alex filter design. > > > 73, Joe K5SO > > On Aug 24, 2014, at 6:38 AM, Brian D wrote: > >> Joe Martin K5SO wrote: >> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> All, >>> >>> Angelia_v4.2 firmware is available for download from >>> >>> http://k5so.com/HPSDR_downloads.html >>> >> Is this suitable for use in the ANAN range of tranceivers or does it need to >> be changed by Abhi for the different filter frequencies? >> >> -- >> Brian D >> G3VGZ >> >> --- >> This email is free from viruses and malware because avast! Antivirus protection is active. >> http://www.avast.com >> > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From bjablonski at att.net Sun Aug 24 11:33:14 2014 From: bjablonski at att.net (Barry Jablonski) Date: Sun, 24 Aug 2014 14:33:14 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> Message-ID: <53FA2FEA.1080501@att.net> Hi Joe, I should know this, but -- where is the FPGA source code located? Barry WB2ZXJ From wb9qzb_groups at yahoo.com Sun Aug 24 11:34:29 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Sun, 24 Aug 2014 11:34:29 -0700 Subject: [hpsdr] Banquet Speaker & Sunday Seminar Annouced at ARRL/TAPR DCC (Digital Communications Conference), Austin, TX, 9/5 - 9/7 In-Reply-To: <1408905113.46795.YahooMailNeo@web140204.mail.bf1.yahoo.com> References: <53EDF934.8040708@sbcglobal.net> <1408905113.46795.YahooMailNeo@web140204.mail.bf1.yahoo.com> Message-ID: <1408905269.81493.YahooMailNeo@web140204.mail.bf1.yahoo.com> The 2014 ARRL/TAPR DCC?Saturday Night Banquet Speaker & Topic?will be? Gerald Youngblood, K5SDR presenting?"Accidental Company, the making of Flex Radio" ----- Forwarded Message ----- From: Stan Horzepa To: tapr-announce at tapr.org Sent: Friday, August 15, 2014 7:12 AM Subject: [tapr-announce] DCC in 3 weeks The 2014 ?ARRL/TAPR DCC will be on Friday, September 5th through Sunday, September 7th at the Austin Marriott South in Austin, Texas. The DCC has two days of technical forums on Friday and Saturday and a concurrent introductory forum on Saturday.? On Saturday night, the banquet will feature an interesting speaker andthe Sunday morning seminar will be "Introduction to SoC FPGA Programming for Mixed Signal Systems" by Chris Testa, KD2BMH. There will be free tables in the demo room to demonstrate projects and vendors to demonstrate products. Time is running out, so those interested in attending should register for the DCC and make hotel reservations ASAP. More DCC information is available at:?www.tapr.org/dcc? ? _______________________________________________ tapr-announce mailing list -------------- next part -------------- An HTML attachment was scrubbed... URL: From pa5bw at xs4all.nl Sun Aug 24 11:55:16 2014 From: pa5bw at xs4all.nl (Ben Witvliet) Date: Sun, 24 Aug 2014 20:55:16 +0200 Subject: [hpsdr] QSK question Message-ID: <81f5d1436d8c0bb8218afb700688ca0a.squirrel@webmail.xs4all.nl> Dear all, I hesistating to switch from my FT990 to an ANAN-200D as my primary RIG as I love the superb quality of the HPSDR receiver and I got hooked on the overview that the waterfall display offer. But I'm also a fanatic DX-er and CW QSK adept, and therefore CAN't LIVE without QSK ;-) I had Erik PA3DES demonstrate the ANAN-10D (HPSDR Hermes) to me with QSK on, but we could not get it working properly. Of course with paddle and headphones connected directly to the ANAN hardware. The switching seems fast enough, but after every dash or dit the AGC of the receiver has to slowly come back to normal, making it impossible to hear anything in between the CW symbols. (1) Any experienced HPSDR user and CW-er here that can tell me what settings we have wrong? (2) Any HPSDR user in The Netherlands that has experience with HF DX-ing in CW and with QSK willing to give a demo of his HPSDR station? Kindest regards, 73, Ben PE5B / PA5BW / 5R8DS From k5so at valornet.com Sun Aug 24 13:07:25 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 24 Aug 2014 14:07:25 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53FA2FEA.1080501@att.net> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> <53FA2FEA.1080501@att.net> Message-ID: <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> Hi Barry, The source code for all of the OpenHPSDR boards is located on the SVN. For Hermes as an example, the source code can be found at http://svn.tapr.org/repos_sdr_hpsdr/trunk/Hermes/Source/Hermes_v2.9/Heremes_v2.9.qar Similarly for Metis, Ozy, Mercury, and Penelope. For Angelia and Orion the source code is available on both my website download page within the firmware download zipped folder http://k5so.com/HPSDR_downloads.html and the Apache Labs download page (sorry, I don?t have the URL for that handy). The source code is generally stored in the form of a *.qar file, which is the Quartus II archive file format. It can be opened and edited and re-compiled if you wish using Quartus II. 73, Joe K5SO On Aug 24, 2014, at 12:33 PM, Barry Jablonski wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Joe, > > I should know this, but -- where is the FPGA source code located? > > Barry > WB2ZXJ From bjablonski at att.net Sun Aug 24 13:20:31 2014 From: bjablonski at att.net (Barry Jablonski) Date: Sun, 24 Aug 2014 16:20:31 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> <53FA2FEA.1080501@att.net> <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> Message-ID: <53FA490F.9040102@att.net> Thank you very much Joe for the info. I guess that I will have to reinstall Tortoise SVN on the Win7/64 Pro machine. It was on the old XP/32 SP3 box, but I failed to bring it forward. Barry WB2ZXJ On 8/24/2014 4:07 PM, Joe Martin K5SO wrote: > Hi Barry, > > The source code for all of the OpenHPSDR boards is located on the SVN. For Hermes as an example, the source code can be found at > > http://svn.tapr.org/repos_sdr_hpsdr/trunk/Hermes/Source/Hermes_v2.9/Heremes_v2.9.qar > > Similarly for Metis, Ozy, Mercury, and Penelope. > > For Angelia and Orion the source code is available on both my website download page within the firmware download zipped folder > > http://k5so.com/HPSDR_downloads.html > > and the Apache Labs download page (sorry, I don?t have the URL for that handy). > > The source code is generally stored in the form of a *.qar file, which is the Quartus II archive file format. It can be opened and edited and re-compiled if you wish using Quartus II. > > 73, Joe K5SO > > On Aug 24, 2014, at 12:33 PM, Barry Jablonski wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Joe, >> >> I should know this, but -- where is the FPGA source code located? >> >> Barry >> WB2ZXJ > From lstoskopf at cox.net Sun Aug 24 15:52:53 2014 From: lstoskopf at cox.net (lstoskopf at cox.net) Date: Sun, 24 Aug 2014 18:52:53 -0400 Subject: [hpsdr] Buy Jetson board? Message-ID: <20140824185253.KI4BB.171489.imail@eastrmwml114> Scotty has the new processor board coming out for his boards and I'm on board (!) when they are out. Ending up here with a pile of development boards (I don't mind). Is there enough SDR coming out/planned to buy a Jetson board and be a passive user or wait for the bigger version or ????????? Fun to try to keep up with the bleeding edge. N0UU From kv0s.dave at gmail.com Sun Aug 24 16:48:36 2014 From: kv0s.dave at gmail.com (Dave Larsen) Date: Sun, 24 Aug 2014 18:48:36 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53FA490F.9040102@att.net> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> <53FA2FEA.1080501@att.net> <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> <53FA490F.9040102@att.net> Message-ID: Barry - Just to let you and others know SVN Software works but you can download files one at time from the web interface and since all tha verlog file are in a *.qar file it may be easier to just use the web interface svn.tapr.org Dave KV0S On Aug 24, 2014 3:20 PM, "Barry Jablonski" wrote: > Thank you very much Joe for the info. > > I guess that I will have to reinstall Tortoise SVN on the Win7/64 Pro > machine. It was on the old XP/32 SP3 box, but I failed to bring it forward. > > Barry > WB2ZXJ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gokoyev+k3it at gmail.com Mon Aug 25 08:43:55 2014 From: gokoyev+k3it at gmail.com (k3it) Date: Mon, 25 Aug 2014 11:43:55 -0400 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) Message-ID: Is there an easy way to identify which radios need a correction for 10/12m coils? Vasiliy On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > The short answer is yes, but if you happen to have an ANAN-series radio > that has incorrect number of windings on the 10/12m filter toroids you will > experience low output power on 10m. > > > Excuse me. A more accurate statement would?ve been: > > "The short answer is yes, but if you happen to have an ANAN-series radio > that has incorrect number of windings on the 10/12m filter toroids you will > experience a lower maximum output power on 10m than you will if the > windings are correct.? > > 73, Joe K5SO > > > On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: > > > ***** High Performance Software Defined Radio Discussion List ***** > > > > Hi Brian, > > > > The short answer is yes, but if you happen to have an ANAN-series radio > that has incorrect number of windings on the 10/12m filter toroids you will > experience low output power on 10m. > > > > The firmware uses correct switch-point frequencies for the Alex filter > set, which is also the correct switch-point frequencies for the ANAN-series > radios that have the correct windings on their filters. It is my > understanding that later versions of the ANAN series radios use correct > windings on their 10/12m filters so their switch points should be identical > to those in Alex. Earlier versions of the ANAN series radios do not. > > > > The firmware ?patch? used initially by Abhi to correct the 10m low power > output for some ANAN series radios is not the ideal method for correcting > the issue of low power output on 10m on those earlier ANAN radios, as the > issue is actually a hardware issue, not a firmware or software issue. If > Abhi wishes to create a version of firmware that uses different switch > points from Alex that?s his prerogative but you should be aware that the > issue is not actually a firmware issue, it?s a hardware issue. > > > > The fact is that there should be only a single firmware version to use > with each of the Hermes, Angelia, and Orion boards, respectively, > regardless of whether the board are used in an ANAN-series configuration > with the Apache Labs filters or in a stand alone configuration using Alex > filters. The "correct fix? for ANAN radios that have the low power output > issue on 10m is to rewind the filter toroids for the 10/12 m filters on > those radios, not to patch the firmware or software to use switch points > that are different from the Alex filter design. > > > > > > 73, Joe K5SO > > > > On Aug 24, 2014, at 6:38 AM, Brian D wrote: > > > >> Joe Martin K5SO wrote: > >> > >>> ***** High Performance Software Defined Radio Discussion List ***** > >>> > >>> All, > >>> > >>> Angelia_v4.2 firmware is available for download from > >>> > >>> http://k5so.com/HPSDR_downloads.html > >>> > >> Is this suitable for use in the ANAN range of tranceivers or does it > need to > >> be changed by Abhi for the different filter frequencies? > >> > >> -- > >> Brian D > >> G3VGZ > >> > >> --- > >> This email is free from viruses and malware because avast! Antivirus > protection is active. > >> http://www.avast.com > >> > > > > _______________________________________________ > > HPSDR Discussion List > > To post msg: hpsdr at openhpsdr.org > > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > > HPSDR web page: http://openhpsdr.org > > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 25 09:25:10 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 25 Aug 2014 10:25:10 -0600 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: It is my understanding that L15 should have 8 turns and L16 should have 9 turns, both of 22 AWG wire. If they do not, then you may observe a lower output power on 10m Tx than you would otherwise. 73, Joe K5SO On Aug 25, 2014, at 9:43 AM, k3it wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Is there an easy way to identify which radios need a correction for 10/12m coils? > > Vasiliy > > > On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. > > > Excuse me. A more accurate statement would?ve been: > > "The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience a lower maximum output power on 10m than you will if the windings are correct.? > > 73, Joe K5SO > > > On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: > > > ***** High Performance Software Defined Radio Discussion List ***** > > > > Hi Brian, > > > > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. > > > > The firmware uses correct switch-point frequencies for the Alex filter set, which is also the correct switch-point frequencies for the ANAN-series radios that have the correct windings on their filters. It is my understanding that later versions of the ANAN series radios use correct windings on their 10/12m filters so their switch points should be identical to those in Alex. Earlier versions of the ANAN series radios do not. > > > > The firmware ?patch? used initially by Abhi to correct the 10m low power output for some ANAN series radios is not the ideal method for correcting the issue of low power output on 10m on those earlier ANAN radios, as the issue is actually a hardware issue, not a firmware or software issue. If Abhi wishes to create a version of firmware that uses different switch points from Alex that?s his prerogative but you should be aware that the issue is not actually a firmware issue, it?s a hardware issue. > > > > The fact is that there should be only a single firmware version to use with each of the Hermes, Angelia, and Orion boards, respectively, regardless of whether the board are used in an ANAN-series configuration with the Apache Labs filters or in a stand alone configuration using Alex filters. The "correct fix? for ANAN radios that have the low power output issue on 10m is to rewind the filter toroids for the 10/12 m filters on those radios, not to patch the firmware or software to use switch points that are different from the Alex filter design. > > > > > > 73, Joe K5SO > > > > On Aug 24, 2014, at 6:38 AM, Brian D wrote: > > > >> Joe Martin K5SO wrote: > >> > >>> ***** High Performance Software Defined Radio Discussion List ***** > >>> > >>> All, > >>> > >>> Angelia_v4.2 firmware is available for download from > >>> > >>> http://k5so.com/HPSDR_downloads.html > >>> > >> Is this suitable for use in the ANAN range of tranceivers or does it need to > >> be changed by Abhi for the different filter frequencies? > >> > >> -- > >> Brian D > >> G3VGZ > >> > >> --- > >> This email is free from viruses and malware because avast! Antivirus protection is active. > >> http://www.avast.com > >> > > > > _______________________________________________ > > HPSDR Discussion List > > To post msg: hpsdr at openhpsdr.org > > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > > HPSDR web page: http://openhpsdr.org > > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 25 09:36:31 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 25 Aug 2014 10:36:31 -0600 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: <2E9C3C33-83C3-4A84-A93C-24EEBD89753C@valornet.com> References: <2E9C3C33-83C3-4A84-A93C-24EEBD89753C@valornet.com> Message-ID: It is my further understanding that radios that have the 100W PA and were shipped after March 2014 have the correct number of windings on the 10/12m LPF toroids. 73, Joe K5SO On Aug 25, 2014, at 10:25 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > It is my understanding that L15 should have 8 turns and L16 should have 9 turns, both of 22 AWG wire. > > If they do not, then you may observe a lower output power on 10m Tx than you would otherwise. > > 73, Joe K5SO > > > On Aug 25, 2014, at 9:43 AM, k3it wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Is there an easy way to identify which radios need a correction for 10/12m coils? >> >> Vasiliy > From abhiarunoday at gmail.com Mon Aug 25 09:53:03 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Mon, 25 Aug 2014 22:23:03 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: Hi Vasiliy, The Original Angelia/Orion firmware extends the 17/15M LPF upto 27Mhz so that 12M is incorporated within this LPF, the Hermes firmware is modified to the (B) version by me to enable this, Firmware that you download from the Apache website incorporates this change, 73s, Abhi On Mon, Aug 25, 2014 at 9:13 PM, k3it wrote: > Is there an easy way to identify which radios need a correction for 10/12m > coils? > > Vasiliy > > > On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO > wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> >> >> Excuse me. A more accurate statement would?ve been: >> >> "The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience a lower maximum output power on 10m than you will if the >> windings are correct.? >> >> 73, Joe K5SO >> >> >> On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: >> >> > ***** High Performance Software Defined Radio Discussion List ***** >> > >> > Hi Brian, >> > >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> > >> > The firmware uses correct switch-point frequencies for the Alex filter >> set, which is also the correct switch-point frequencies for the ANAN-series >> radios that have the correct windings on their filters. It is my >> understanding that later versions of the ANAN series radios use correct >> windings on their 10/12m filters so their switch points should be identical >> to those in Alex. Earlier versions of the ANAN series radios do not. >> > >> > The firmware ?patch? used initially by Abhi to correct the 10m low >> power output for some ANAN series radios is not the ideal method for >> correcting the issue of low power output on 10m on those earlier ANAN >> radios, as the issue is actually a hardware issue, not a firmware or >> software issue. If Abhi wishes to create a version of firmware that uses >> different switch points from Alex that?s his prerogative but you should be >> aware that the issue is not actually a firmware issue, it?s a hardware >> issue. >> > >> > The fact is that there should be only a single firmware version to use >> with each of the Hermes, Angelia, and Orion boards, respectively, >> regardless of whether the board are used in an ANAN-series configuration >> with the Apache Labs filters or in a stand alone configuration using Alex >> filters. The "correct fix? for ANAN radios that have the low power output >> issue on 10m is to rewind the filter toroids for the 10/12 m filters on >> those radios, not to patch the firmware or software to use switch points >> that are different from the Alex filter design. >> > >> > >> > 73, Joe K5SO >> > >> > On Aug 24, 2014, at 6:38 AM, Brian D wrote: >> > >> >> Joe Martin K5SO wrote: >> >> >> >>> ***** High Performance Software Defined Radio Discussion List ***** >> >>> >> >>> All, >> >>> >> >>> Angelia_v4.2 firmware is available for download from >> >>> >> >>> http://k5so.com/HPSDR_downloads.html >> >>> >> >> Is this suitable for use in the ANAN range of tranceivers or does it >> need to >> >> be changed by Abhi for the different filter frequencies? >> >> >> >> -- >> >> Brian D >> >> G3VGZ >> >> >> >> --- >> >> This email is free from viruses and malware because avast! Antivirus >> protection is active. >> >> http://www.avast.com >> >> >> > >> > _______________________________________________ >> > HPSDR Discussion List >> > To post msg: hpsdr at openhpsdr.org >> > Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> > HPSDR web page: http://openhpsdr.org >> > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhiarunoday at gmail.com Mon Aug 25 10:22:48 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Mon, 25 Aug 2014 22:52:48 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this, 73s, Abhi On Monday, August 25, 2014, k3it wrote: > Is there an easy way to identify which radios need a correction for 10/12m > coils? > > Vasiliy > > > On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO > wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> >> >> Excuse me. A more accurate statement would?ve been: >> >> "The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience a lower maximum output power on 10m than you will if the >> windings are correct.? >> >> 73, Joe K5SO >> >> >> On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: >> >> > ***** High Performance Software Defined Radio Discussion List ***** >> > >> > Hi Brian, >> > >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> > >> > The firmware uses correct switch-point frequencies for the Alex filter >> set, which is also the correct switch-point frequencies for the ANAN-series >> radios that have the correct windings on their filters. It is my >> understanding that later versions of the ANAN series radios use correct >> windings on their 10/12m filters so their switch points should be identical >> to those in Alex. Earlier versions of the ANAN series radios do not. >> > >> > The firmware ?patch? used initially by Abhi to correct the 10m low >> power output for some ANAN series radios is not the ideal method for >> correcting the issue of low power output on 10m on those earlier ANAN >> radios, as the issue is actually a hardware issue, not a firmware or >> software issue. If Abhi wishes to create a version of firmware that uses >> different switch points from Alex that?s his prerogative but you should be >> aware that the issue is not actually a firmware issue, it?s a hardware >> issue. >> > >> > The fact is that there should be only a single firmware version to use >> with each of the Hermes, Angelia, and Orion boards, respectively, >> regardless of whether the board are used in an ANAN-series configuration >> with the Apache Labs filters or in a stand alone configuration using Alex >> filters. The "correct fix? for ANAN radios that have the low power output >> issue on 10m is to rewind the filter toroids for the 10/12 m filters on >> those radios, not to patch the firmware or software to use switch points >> that are different from the Alex filter design. >> > >> > >> > 73, Joe K5SO >> > >> > On Aug 24, 2014, at 6:38 AM, Brian D wrote: >> > >> >> Joe Martin K5SO > > wrote: >> >> >> >>> ***** High Performance Software Defined Radio Discussion List ***** >> >>> >> >>> All, >> >>> >> >>> Angelia_v4.2 firmware is available for download from >> >>> >> >>> http://k5so.com/HPSDR_downloads.html >> >>> >> >> Is this suitable for use in the ANAN range of tranceivers or does it >> need to >> >> be changed by Abhi for the different filter frequencies? >> >> >> >> -- >> >> Brian D >> >> G3VGZ >> >> >> >> --- >> >> This email is free from viruses and malware because avast! Antivirus >> protection is active. >> >> http://www.avast.com >> >> >> > >> > _______________________________________________ >> > HPSDR Discussion List >> > To post msg: hpsdr at openhpsdr.org >> >> > Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> > HPSDR web page: http://openhpsdr.org >> > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjablonski at att.net Mon Aug 25 10:31:25 2014 From: bjablonski at att.net (Barry Jablonski) Date: Mon, 25 Aug 2014 13:31:25 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53FB72ED.8060107@att.net> Thanks for that information Dave. I'm mainly interested in the Hermes FPGA code and this will save me time. I also just found out I will have to downgrade Quartus II from v14 to v13.1 since the latest version has dropped support for Cyclone III devices. Barry WB2ZXJ From mstangelo at comcast.net Mon Aug 25 12:49:23 2014 From: mstangelo at comcast.net (mstangelo at comcast.net) Date: Mon, 25 Aug 2014 19:49:23 +0000 (UTC) Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> Abhi, You responded with: "Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this," You also had an issue low power with 12M. Do we need your special code to switcg in different LP filters for the 12 Meter band? Mike N2MS ----- Original Message ----- From: Abhi A To: k3it Cc: HPSDR list Sent: Mon, 25 Aug 2014 17:22:48 -0000 (UTC) Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** From gregg.w6izt1 at gmail.com Mon Aug 25 12:55:49 2014 From: gregg.w6izt1 at gmail.com (Gregg W6IZT) Date: Mon, 25 Aug 2014 15:55:49 -0400 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> References: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> Message-ID: <047601cfc09e$91ea2240$b5be66c0$@gmail.com> I had the low power issue on 12 m and a change to the FW resolved it. I'd prefer to address a HW problem in HW by adjusting the inductors in the LPF to have the correct number of turns. I now have that information on the correct number of turns for the inductors in question. Question: Will I need to change the FW if I correct the inductors? Gregg W6IZT -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of mstangelo at comcast.net Sent: Monday, August 25, 2014 3:49 PM To: Abhi A Cc: HPSDR list Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** Abhi, You responded with: "Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this," You also had an issue low power with 12M. Do we need your special code to switcg in different LP filters for the 12 Meter band? Mike N2MS ----- Original Message ----- From: Abhi A To: k3it Cc: HPSDR list Sent: Mon, 25 Aug 2014 17:22:48 -0000 (UTC) Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From ka6tya at arrl.net Mon Aug 25 13:22:35 2014 From: ka6tya at arrl.net (Pat McGrath) Date: Mon, 25 Aug 2014 13:22:35 -0700 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: <047601cfc09e$91ea2240$b5be66c0$@gmail.com> References: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> <047601cfc09e$91ea2240$b5be66c0$@gmail.com> Message-ID: <000301cfc0a2$4ed683f0$ec838bd0$@arrl.net> Abhi A Will your company permanently fix the problem? -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Gregg W6IZT Sent: Monday, August 25, 2014 12:56 PM To: mstangelo at comcast.net; 'Abhi A' Cc: 'HPSDR list' Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** I had the low power issue on 12 m and a change to the FW resolved it. I'd prefer to address a HW problem in HW by adjusting the inductors in the LPF to have the correct number of turns. I now have that information on the correct number of turns for the inductors in question. Question: Will I need to change the FW if I correct the inductors? Gregg W6IZT -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of mstangelo at comcast.net Sent: Monday, August 25, 2014 3:49 PM To: Abhi A Cc: HPSDR list Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** Abhi, You responded with: "Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this," You also had an issue low power with 12M. Do we need your special code to switcg in different LP filters for the 12 Meter band? Mike N2MS ----- Original Message ----- From: Abhi A To: k3it Cc: HPSDR list Sent: Mon, 25 Aug 2014 17:22:48 -0000 (UTC) Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From abhiarunoday at gmail.com Mon Aug 25 20:46:58 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Tue, 26 Aug 2014 09:16:58 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) Message-ID: Hi Guys, I think there is some confusion here, all ANAN radios use the 17/15M LPF on 12M as well, changing the coils on the 10M LPF does not effect the 12M output, The change in the 10M LPF was to prevent low output on the 10M band in some radios, if you are not experiencing low power on 10M this does not effect you, The Orion and Angelia firmware already have this change coded in, the Original Hermes firmware does not, hence, Apache releases a B version which incorporates this change, 73s, Abhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Mon Aug 25 21:53:53 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Mon, 25 Aug 2014 23:53:53 -0500 Subject: [hpsdr] Fwd: RE: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: Is it just me or does the fwd pwr TX meter seem to be to be reading lower than it should with this release? I was checking power outputs and it seems to be about 15 watts lower than reality. Is this just me? I was trying to adjust output power and that's when I realized it. I reset databases just to be sure. I didn't notice this on 3.2.17. 73, Jae - K5JAE -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhiarunoday at gmail.com Mon Aug 25 22:38:55 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Tue, 26 Aug 2014 11:08:55 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) Message-ID: Further update and correction: The 10M Coil update also fixes the 12M low power output, however, using the 17/15M LPF for 12M also works, The current Orion firmware uses the 10M LPF for 12M, all 200Ds shipped have the LPF change incorporated, The Angelia and Hermes (B) Firmware uses the 17/15M LPF for 12M, I believe all radios shipped from March 2014 as Joe indicated have this change incorporated, In case you are experiencing low output on 12/10M please contact Apache Support and we will be happy to assist in resolving this issue, 73s, Abhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian13434 at yahoo.co.uk Tue Aug 26 02:54:53 2014 From: brian13434 at yahoo.co.uk (Brian D) Date: Tue, 26 Aug 2014 10:54:53 +0100 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: Jae Stutzman wrote: > Is it just me or does the fwd pwr TX meter seem to be to be reading lower > than it should with this release? I was checking power outputs and it > seems to be about 15 watts lower than reality. Is this just me? I was > trying to adjust output power and that's when I realized it. I reset > databases just to be sure. I didn't notice this on 3.2.17. I haven't noticed it reading low but I've had several times it reading NaN for VSWR when tuning into the goood match of my test load. Not sure at this stage if it is the new version of HPSDR or my recent firmware upgrade to 4.2 (angelia). -- Brian D G3VGZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From k5jae at stutzman.net Tue Aug 26 05:38:52 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Tue, 26 Aug 2014 07:38:52 -0500 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: I should have mentioned that I recently upgraded to 4.2 Angelia as well. So it could be either. I'll try downgrading back to 4.1 to see if that changes anything. I noticed it with TUN and it was reading out about 85W for each band. I was originally trying to find out if I was affected by the 10M winding issue. On Tue, Aug 26, 2014 at 4:54 AM, Brian D wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Jae Stutzman wrote: > > > Is it just me or does the fwd pwr TX meter seem to be to be reading lower > > than it should with this release? I was checking power outputs and it > > seems to be about 15 watts lower than reality. Is this just me? I was > > trying to adjust output power and that's when I realized it. I reset > > databases just to be sure. I didn't notice this on 3.2.17. > > I haven't noticed it reading low but I've had several times it reading NaN > for VSWR when tuning into the goood match of my test load. Not sure at this > stage if it is the new version of HPSDR or my recent firmware upgrade to > 4.2 > (angelia). > > > -- > Brian D > G3VGZ > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernd.gasser at tele2.at Tue Aug 26 06:01:36 2014 From: bernd.gasser at tele2.at (Bernd Gasser) Date: Tue, 26 Aug 2014 15:01:36 +0200 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <008001cfc12d$dea6b4b0$9bf41e10$@tele2.at> Hi Hermann et al, after seeing all your interesting messages I was also infected by the cuda-virus and ordered a Jetson TK1 to play with. So far I managed to set it up with Qt5.4 and cuda-6.0 installed and I have successfully compiled cuSDR64 and ghpsdr-alex on it which both seems to run fine with a little high CPU-load. (cuSDR64 shows abt 155%). When looking at the shared libraries mapped to the running binary I noticed it is still using the 'standard libfftw3' library instead of the ones optimized for the TEGRA 192 GPU cores supplied with cuda-6.0. UID PID PPID C STIME TTY TIME CMD ubuntu 2942 2607 99 12:07 pts/4 00:38:25 ./cuSDR64 ubuntu at tegra-ubuntu:/proc/2942$ grep fftw maps b6665000-b67ad000 r-xp 00000000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 b67ad000-b67b4000 ---p 00148000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 b67b4000-b67bc000 r--p 00147000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 b67bc000-b67bd000 rw-p 0014f000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 What would be the required change in the build environment to make use of the cuda-6.0 libraries in /usr/local/cuda-6.0/lib/libcufftw* ? - Has anyone done this yet and could give me some pointers? tnx & 73, Bernd/OE1ACM -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von Hermann Gesendet: Montag, 18. August 2014 13:24 An: Chris Smith; hpsdr at lists.openhpsdr.org Betreff: Re: [hpsdr] 20140126cuSDR64 & TK1 ***** High Performance Software Defined Radio Discussion List ***** From gokoyev+k3it at gmail.com Tue Aug 26 06:23:48 2014 From: gokoyev+k3it at gmail.com (k3it) Date: Tue, 26 Aug 2014 09:23:48 -0400 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <008001cfc12d$dea6b4b0$9bf41e10$@tele2.at> References: <20140817163704.A6AAD48278@diego.dreamhost.com> <008001cfc12d$dea6b4b0$9bf41e10$@tele2.at> Message-ID: Here is a link that describes what needs to be done to convert to cufftw http://docs.nvidia.com/cuda/cufft/index.html#fftw-supported-interface But this looks too easy to be true :) I haven't tried it. Also running Jetson board here with gphpsdr3 73 Vasiliy On Tue, Aug 26, 2014 at 9:01 AM, Bernd Gasser wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Hermann et al, > after seeing all your interesting messages I was also infected by the > cuda-virus and ordered a Jetson TK1 to play with. > > So far I managed to set it up with Qt5.4 and cuda-6.0 installed and I have > successfully compiled cuSDR64 and ghpsdr-alex on it which both seems to run > fine with a little high CPU-load. (cuSDR64 shows abt 155%). > > When looking at the shared libraries mapped to the running binary I noticed > it is still using the 'standard libfftw3' library instead of the ones > optimized for the TEGRA 192 GPU cores supplied with cuda-6.0. > > > UID PID PPID C STIME TTY TIME CMD > ubuntu 2942 2607 99 12:07 pts/4 00:38:25 ./cuSDR64 > > ubuntu at tegra-ubuntu:/proc/2942$ grep fftw maps > b6665000-b67ad000 r-xp 00000000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > b67ad000-b67b4000 ---p 00148000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > b67b4000-b67bc000 r--p 00147000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > b67bc000-b67bd000 rw-p 0014f000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > > What would be the required change in the build environment to make use of > the cuda-6.0 libraries in /usr/local/cuda-6.0/lib/libcufftw* ? - Has > anyone > done this yet and could give me some pointers? > > tnx & 73, > Bernd/OE1ACM > > > > > > > > -----Urspr?ngliche Nachricht----- > Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von > Hermann > Gesendet: Montag, 18. August 2014 13:24 > An: Chris Smith; hpsdr at lists.openhpsdr.org > Betreff: Re: [hpsdr] 20140126cuSDR64 & TK1 > > ***** High Performance Software Defined Radio Discussion List ***** > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnlaur at gmail.com Tue Aug 26 08:08:04 2014 From: johnlaur at gmail.com (John Laur) Date: Tue, 26 Aug 2014 10:08:04 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: Ideas for discussion: First, isn't this similar to the architecture that has been implemented by PA3FWM's wideband websdr for some time? ADC->FPGA->Ethernet->FFT with GPU and then individual receivers only have to grab the bins and do an IFFT? If so, it's a clear winner as far as scaling the capabilities go. I am very excited to see the excitement for it. But I am concerned with the discussion dwelling around the Jetson board as being central and essential to this architecture long-term although I do think it is valuable as a motivator. For a hardware architecture that will hang around for a while and be the most compatible, I would like to discuss the option of designing instead for regular (non-mini) PCI-e. While it's great to have these 'fun-size' SBC's there is really nothing that I have seen to conclude that NVidia or a 3rd party will continue to ship such a thing as a developer or retail product with extremely similar architecture and form factor over the long term. So unless there is someone who wants to keep up with the hassle of actually integrating NVidia silicon onto an HPSDR board and making a wholly integrated system a la the Flex-6k, I do not think it is worth exploring too far into that paradigm. Designing for the Jetson's mini-pcie interface would severely limit future flexibility should the product be dropped and limit the use of the HPSDR hardware in cases where mini-pcie is not available on a board with a suitable CUDA GPU. Plus, Jetson itself has a huge disadvantage (for the HPSDR server application) of having only a single Ethernet interface. I understand that there is still 16Mbps of bandwidth 'left over' (and that the interface itself is full duplex) but that is an awfully limiting margin considering the possibilities that exist with the architecture. Yes; one could be added on USB without occupying the mini-PCIe, but at the expense of the limited CPU resources. Running ethernet interfaces at 99% capacity is a tricky business anyway. It would be nice to simply eliminate that challenge. There is one thing we can be sure of though: NVidia will continue to ship regular PCI-e graphics cards for the foreseeable future. Depending on the version of CUDA required, an inexpensive NVidia GeForce card will likely exceed Jetson's performance by quite a lot. A small dedicated system with dual PCIe slots and a GPU can be designed and built with specifications exceeding those of the Jetson board at similar cost, and the same architecture can be implemented. I do not see that the Jetson has any advantage over such system other than perhaps power consumption or having fixed design. The problem of power consumption is likely not to be a large concern in this application, and the second problem can be eliminated by specifying a tested reference design. * PCI-e is the fastest common interface available. Current standards take speeds to 250gbps (PCI-e 4.0 x16), and even the lowest common denominator (PCI-e 1.0 1x) is still 2gbps. * PCI-e can be bridged to Mini-PCIe, Thunderbolt, or Expresscard interfaces with off-the-shelf hardware. * PCI-e supports DMA, RDMA, and peer to peer data transfer. Data can be moved from HPDSR to GPU without involving the CPU. A passive PCI-e backplane could be used as a future replacement for Atlas with the ability to use off the shelf parts. * PCI-e is easy to interface in the modern Altera FPGAs with hardware controllers and does not require the difficult task of writing IP for 3rd party interface chips (Existing IP for things like USB 3.0 controllers and 10gbE chips are licensed and generally not compatible with open-source licenses. I believe this is one of the major pain points with the current HPSDR FPGA efforts.) * PCI-e is generally backwards (and forwards!) compatible. So modern high-bandwidth hardware can be designed and still used with older or less powerful hosts. An external interface of some sort has the advantage that the RF bits can be somewhat isolated from the noisy computer bits, but there are ways to mitigate that and still use PCI-e, such as using a case design that ensures the RF side is well shielded. The design could also be broken into two parts with the ADC/DAC/Clocks isolated and connected to the FPGA on a PCI-e card by means of line driver ICs and off-the-shelf cables. Any thoughts from those more involved with the software or hardware design? 73, John KF5SAB On Fri, Aug 22, 2014 at 10:31 PM, Phil Harman wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Marc, > > Thanks for your email. > > We still have a way to go with fully proving the DFC idea but so far its looking good. > > We actually had this discussion a few minutes ago during the weekly Teamspeak session. > > Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. > > What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. > > What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. > > With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. > > If such a PCB design is of interest to you then please lets discuss further. > > 73 Phil....VK6PH > > > -----Original Message----- From: Marc Lalonde > Sent: Saturday, August 23, 2014 10:31 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > guess some one already work on a ADC /DAC Board that go on the expansion > connector of the DEV kit ? > seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA > as Glue logic.. > > that may remove the LAN / PHY from equation and permit made nice self > contained platform ;-) > > if no one yet ,i may willing to help work on this ,i was a senior PCB > designer whit some design backgrond .. > > Best 73! > Marc VE2OLM From k5so at valornet.com Tue Aug 26 09:35:24 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Tue, 26 Aug 2014 10:35:24 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <3AD73732-607A-4AB5-96C3-5B78FB0B1477@valornet.com> Hi John, I completely agree with your analysis and have in fact privately expressed to several people my concern regarding use of a (marginally powerful) single board computer in the mix. But keep in mind that the new protocol that Phil is contemplating will work fine with either a single powerful computer (SBC) connected to the hardware OR with a high performance computer connected to the hardware as we have traditionally done. Therefore the SBC development activity underway doesn?t limit things at all for those of us who would prefer to use a single high performance computer instead. Users of a single high performance computer can still exploit the new protocol and realize the same flexibility and performance benefits that Phil mentioned that are associated with the new proposed ethernet protocol. The Jetson board SBC approach is simply an activity that is running in parallel with the original architecture scheme. Whether you wish to use an SBC configuration or not is entirely optional and open to your personal preference. I?ve come to realize that we?re not losing anything at all by having some people working on SBC configurations in order to have low-performance hand held devices able to interface the hardware (if that happens to be your personal interest). 73, Joe K5SO From dc6ny at gmx.de Tue Aug 26 09:36:24 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Tue, 26 Aug 2014 18:36:24 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <000001cfc14b$e0b5c2f0$a22148d0$@de> Nice reasoning, John. Thanks. 73, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von John Laur Gesendet: Dienstag, 26. August 2014 17:08 An: HPSDR list Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Ideas for discussion: First, isn't this similar to the architecture that has been implemented by PA3FWM's wideband websdr for some time? ADC->FPGA->Ethernet->FFT with GPU and then individual receivers only have to grab the bins and do an IFFT? If so, it's a clear winner as far as scaling the capabilities go. I am very excited to see the excitement for it. But I am concerned with the discussion dwelling around the Jetson board as being central and essential to this architecture long-term although I do think it is valuable as a motivator. For a hardware architecture that will hang around for a while and be the most compatible, I would like to discuss the option of designing instead for regular (non-mini) PCI-e. While it's great to have these 'fun-size' SBC's there is really nothing that I have seen to conclude that NVidia or a 3rd party will continue to ship such a thing as a developer or retail product with extremely similar architecture and form factor over the long term. So unless there is someone who wants to keep up with the hassle of actually integrating NVidia silicon onto an HPSDR board and making a wholly integrated system a la the Flex-6k, I do not think it is worth exploring too far into that paradigm. Designing for the Jetson's mini-pcie interface would severely limit future flexibility should the product be dropped and limit the use of the HPSDR hardware in cases where mini-pcie is not available on a board with a suitable CUDA GPU. Plus, Jetson itself has a huge disadvantage (for the HPSDR server application) of having only a single Ethernet interface. I understand that there is still 16Mbps of bandwidth 'left over' (and that the interface itself is full duplex) but that is an awfully limiting margin considering the possibilities that exist with the architecture. Yes; one could be added on USB without occupying the mini-PCIe, but at the expense of the limited CPU resources. Running ethernet interfaces at 99% capacity is a tricky business anyway. It would be nice to simply eliminate that challenge. There is one thing we can be sure of though: NVidia will continue to ship regular PCI-e graphics cards for the foreseeable future. Depending on the version of CUDA required, an inexpensive NVidia GeForce card will likely exceed Jetson's performance by quite a lot. A small dedicated system with dual PCIe slots and a GPU can be designed and built with specifications exceeding those of the Jetson board at similar cost, and the same architecture can be implemented. I do not see that the Jetson has any advantage over such system other than perhaps power consumption or having fixed design. The problem of power consumption is likely not to be a large concern in this application, and the second problem can be eliminated by specifying a tested reference design. * PCI-e is the fastest common interface available. Current standards take speeds to 250gbps (PCI-e 4.0 x16), and even the lowest common denominator (PCI-e 1.0 1x) is still 2gbps. * PCI-e can be bridged to Mini-PCIe, Thunderbolt, or Expresscard interfaces with off-the-shelf hardware. * PCI-e supports DMA, RDMA, and peer to peer data transfer. Data can be moved from HPDSR to GPU without involving the CPU. A passive PCI-e backplane could be used as a future replacement for Atlas with the ability to use off the shelf parts. * PCI-e is easy to interface in the modern Altera FPGAs with hardware controllers and does not require the difficult task of writing IP for 3rd party interface chips (Existing IP for things like USB 3.0 controllers and 10gbE chips are licensed and generally not compatible with open-source licenses. I believe this is one of the major pain points with the current HPSDR FPGA efforts.) * PCI-e is generally backwards (and forwards!) compatible. So modern high-bandwidth hardware can be designed and still used with older or less powerful hosts. An external interface of some sort has the advantage that the RF bits can be somewhat isolated from the noisy computer bits, but there are ways to mitigate that and still use PCI-e, such as using a case design that ensures the RF side is well shielded. The design could also be broken into two parts with the ADC/DAC/Clocks isolated and connected to the FPGA on a PCI-e card by means of line driver ICs and off-the-shelf cables. Any thoughts from those more involved with the software or hardware design? 73, John KF5SAB On Fri, Aug 22, 2014 at 10:31 PM, Phil Harman wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Marc, > > Thanks for your email. > > We still have a way to go with fully proving the DFC idea but so far its looking good. > > We actually had this discussion a few minutes ago during the weekly Teamspeak session. > > Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. > > What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. > > What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. > > With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. > > If such a PCB design is of interest to you then please lets discuss further. > > 73 Phil....VK6PH > > > -----Original Message----- From: Marc Lalonde > Sent: Saturday, August 23, 2014 10:31 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > guess some one already work on a ADC /DAC Board that go on the > expansion connector of the DEV kit ? > seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA > as Glue logic.. > > that may remove the LAN / PHY from equation and permit made nice self > contained platform ;-) > > if no one yet ,i may willing to help work on this ,i was a senior > PCB designer whit some design backgrond .. > > Best 73! > Marc VE2OLM _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From k5so at valornet.com Tue Aug 26 09:38:47 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Tue, 26 Aug 2014 10:38:47 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <3AD73732-607A-4AB5-96C3-5B78FB0B1477@valornet.com> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> <3AD73732-607A-4AB5-96C3-5B78FB0B1477@valornet.com> Message-ID: > ... will work fine with either a single powerful computer (SBC) connected to the hardware OR with a high performance computer connected to the hardware as we have traditionally done. I meant: single board computer (SBC). 73, Joe K5SO On Aug 26, 2014, at 10:35 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi John, > > I completely agree with your analysis and have in fact privately expressed to several people my concern regarding use of a (marginally powerful) single board computer in the mix. But keep in mind that the new protocol that Phil is contemplating will work fine with either a single powerful computer (SBC) connected to the hardware OR with a high performance computer connected to the hardware as we have traditionally done. > > Therefore the SBC development activity underway doesn?t limit things at all for those of us who would prefer to use a single high performance computer instead. Users of a single high performance computer can still exploit the new protocol and realize the same flexibility and performance benefits that Phil mentioned that are associated with the new proposed ethernet protocol. > > The Jetson board SBC approach is simply an activity that is running in parallel with the original architecture scheme. Whether you wish to use an SBC configuration or not is entirely optional and open to your personal preference. I?ve come to realize that we?re not losing anything at all by having some people working on SBC configurations in order to have low-performance hand held devices able to interface the hardware (if that happens to be your personal interest). > > 73, Joe K5SO > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlalonde at alphatronique.com Tue Aug 26 09:43:08 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Tue, 26 Aug 2014 12:43:08 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <53FCB91C.1090209@alphatronique.com> HI mini-PCI-e may put on PCI-e whit common adapter ,then put on standard PC if need or may use PCI-e to PCI-e backplane + CPU of some sort ,so many possibility it need at last 2 lane for a decent SDR (make cation whit Bit Vs Byte) ADC was 12 Bit x 122Mhx and DAC was 14 bit x 122Mhz this may also double in future... so ~ 3.2Gbit/s integrating NVidia silicon onto an HPSDR ,not a thing that i doable at decent cost Best 73! Marc L. VE2OLM On 26/08/2014 11:08 AM, John Laur wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Ideas for discussion: > > First, isn't this similar to the architecture that has been > implemented by PA3FWM's wideband websdr for some time? > ADC->FPGA->Ethernet->FFT with GPU and then individual receivers only > have to grab the bins and do an IFFT? If so, it's a clear winner as > far as scaling the capabilities go. I am very excited to see the > excitement for it. But I am concerned with the discussion dwelling > around the Jetson board as being central and essential to this > architecture long-term although I do think it is valuable as a > motivator. > > For a hardware architecture that will hang around for a while and be > the most compatible, I would like to discuss the option of designing > instead for regular (non-mini) PCI-e. > > While it's great to have these 'fun-size' SBC's there is really > nothing that I have seen to conclude that NVidia or a 3rd party will > continue to ship such a thing as a developer or retail product with > extremely similar architecture and form factor over the long term. So > unless there is someone who wants to keep up with the hassle of > actually integrating NVidia silicon onto an HPSDR board and making a > wholly integrated system a la the Flex-6k, I do not think it is worth > exploring too far into that paradigm. Designing for the Jetson's > mini-pcie interface would severely limit future flexibility should the > product be dropped and limit the use of the HPSDR hardware in cases > where mini-pcie is not available on a board with a suitable CUDA GPU. > Plus, Jetson itself has a huge disadvantage (for the HPSDR server > application) of having only a single Ethernet interface. I understand > that there is still 16Mbps of bandwidth 'left over' (and that the > interface itself is full duplex) but that is an awfully limiting > margin considering the possibilities that exist with the architecture. > Yes; one could be added on USB without occupying the mini-PCIe, but at > the expense of the limited CPU resources. Running ethernet interfaces > at 99% capacity is a tricky business anyway. It would be nice to > simply eliminate that challenge. > > There is one thing we can be sure of though: NVidia will continue to > ship regular PCI-e graphics cards for the foreseeable future. > Depending on the version of CUDA required, an inexpensive NVidia > GeForce card will likely exceed Jetson's performance by quite a lot. A > small dedicated system with dual PCIe slots and a GPU can be designed > and built with specifications exceeding those of the Jetson board at > similar cost, and the same architecture can be implemented. I do not > see that the Jetson has any advantage over such system other than > perhaps power consumption or having fixed design. The problem of power > consumption is likely not to be a large concern in this application, > and the second problem can be eliminated by specifying a tested > reference design. > > * PCI-e is the fastest common interface available. Current standards > take speeds to 250gbps (PCI-e 4.0 x16), and even the lowest common > denominator (PCI-e 1.0 1x) is still 2gbps. > > * PCI-e can be bridged to Mini-PCIe, Thunderbolt, or Expresscard > interfaces with off-the-shelf hardware. > > * PCI-e supports DMA, RDMA, and peer to peer data transfer. Data can > be moved from HPDSR to GPU without involving the CPU. A passive PCI-e > backplane could be used as a future replacement for Atlas with the > ability to use off the shelf parts. > > * PCI-e is easy to interface in the modern Altera FPGAs with hardware > controllers and does not require the difficult task of writing IP for > 3rd party interface chips (Existing IP for things like USB 3.0 > controllers and 10gbE chips are licensed and generally not compatible > with open-source licenses. I believe this is one of the major pain > points with the current HPSDR FPGA efforts.) > > * PCI-e is generally backwards (and forwards!) compatible. So modern > high-bandwidth hardware can be designed and still used with older or > less powerful hosts. > > An external interface of some sort has the advantage that the RF bits > can be somewhat isolated from the noisy computer bits, but there are > ways to mitigate that and still use PCI-e, such as using a case design > that ensures the RF side is well shielded. The design could also be > broken into two parts with the ADC/DAC/Clocks isolated and connected > to the FPGA on a PCI-e card by means of line driver ICs and > off-the-shelf cables. > > Any thoughts from those more involved with the software or hardware design? > > 73, John KF5SAB > > > On Fri, Aug 22, 2014 at 10:31 PM, Phil Harman wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Marc, >> >> Thanks for your email. >> >> We still have a way to go with fully proving the DFC idea but so far its looking good. >> >> We actually had this discussion a few minutes ago during the weekly Teamspeak session. >> >> Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. >> >> What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. >> >> What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. >> >> With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. >> >> If such a PCB design is of interest to you then please lets discuss further. >> >> 73 Phil....VK6PH >> >> >> -----Original Message----- From: Marc Lalonde >> Sent: Saturday, August 23, 2014 10:31 AM >> To: hpsdr at lists.openhpsdr.org >> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >> >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi >> >> guess some one already work on a ADC /DAC Board that go on the expansion >> connector of the DEV kit ? >> seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA >> as Glue logic.. >> >> that may remove the LAN / PHY from equation and permit made nice self >> contained platform ;-) >> >> if no one yet ,i may willing to help work on this ,i was a senior PCB >> designer whit some design backgrond .. >> >> Best 73! >> Marc VE2OLM > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From hvh.net at gmail.com Tue Aug 26 10:40:02 2014 From: hvh.net at gmail.com (Hermann) Date: Tue, 26 Aug 2014 19:40:02 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: Dear John, all, thank you all for your thoughts. Here's my 2-cent: the discussion focus too much on Hardware, and the Jetson board is surely an experimental platform. It doesn't makes much sense to ponder upon if this board has one or two ethernet interfaces. Of course, this does matter if a certain architecture should be tested. Btw, the upcoming Tablets and Handhelds will have chips like the Tegra K1, and in a couple of years even more powerful devices. So, we will indeed have handhelds with super-computing power - at least in a certain sense. Hardware is subject to fast changes, but how do we keep up with the Software? Why do you think is Altera, e.g., providing an interface to OpenCL? Nvidia is doing a really great job in providing not only fast hardware, but also a complete programming model, together with all necessary tools. In a completely different domain (but also embedded), chip providers are building great hardware, with 6 or more cores etc etc., but don't tell the software architects how to program these fine controllers, or how to migrate software, which grew out of 20 years of development (and as such is invaluable). The 'multicore problem' is still not solved (some may claim they have), and the majority of algorithms and code (with some very few exceptions, like FFTs, or matrix multiplication) is NOT easily parallelized. Why does nobody (with very few but remarkable exceptions) take existing code (KISS Console, PowerSDR, cuSDR) and work on it to implement this or that feature? I receive so many emails and comments on the mailing lists, asking for new features. And if it's not going fast enough, people start declaring cuSDR as vaporware, hi. It is not much more difficult, than, as Joe, K5SO has reported so wonderful, start working on code for FPGAs. Hardware changes fast, Software not. The idea of open source is not only that the software is free. Much more important is that a lot of people start contributing to it. For me this is the main message from Phil's original post. 73, Hermann DL3HVH -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcrewson at cinci.rr.com Tue Aug 26 11:45:42 2014 From: rcrewson at cinci.rr.com (Rob Crewson) Date: Tue, 26 Aug 2014 14:45:42 -0400 Subject: [hpsdr] 'Cuda 6.5 Features and OverView'. Message-ID: <000c01cfc15d$f0843830$d18ca890$@cinci.rr.com> To anyone interested in this topic. I just watched a webinar from NVidia on their recent release of Cuda 6.5 -> 'Cuda 6.5 Features and OverView'. I took screenshots of the presentation slides (14) . The last one is of the chat board questions, one which pertained to the 'Jetson tk1' board. If you want a copy of either email me off list @ rcrewson at cinci.rr.com . 73, RobC VE3EW -------------- next part -------------- An HTML attachment was scrubbed... URL: From jra at febo.com Tue Aug 26 12:16:43 2014 From: jra at febo.com (John Ackermann N8UR) Date: Tue, 26 Aug 2014 15:16:43 -0400 Subject: [hpsdr] External T/R switch for PureSignal Message-ID: <53FCDD1B.5010803@febo.com> If you're interested in a kit to provide external T/R switching optimized for PureSignal setups, read on. If you've experimented with PureSignal, you know that the ANAN T/R switching isn't up to the task because (a) it shorts the receiver input to ground during TX, and (b) there is a lot of crosstalk within the switch/filter board. The combination means that you can't get a useful sampler signal into the radio without some sort of modification. Thanks to much help from KC9XG, I found that it's easy on the ANAN-10 to bypass the internal T/R by just removing the RX coax between the Hermes board and the amp board. Then, you can use the Hermes SMA RX connector and get TX from the ANT1 BNC connector. After that, all you need is an external switch. No new holes are required. (I don't own an ANAN-100 but as long as you can route the RX signal directly to the Hermes receive input, the same setup should work.) The external switch needs two relays: one to switch the antenna between TX and RX, and the second to switch the receiver path between antenna on RX and a signal sampler on TX. It needs good isolation for PureSignal (which is where my perfboard prototype with junkbox relays fell short). So, I've laid out a 3 inch (wide) by 1 inch (deep) circuit board with two BNC connectors (ANT and TX) and two SMA connectors (RX and SAMPLE). It uses the same relays as the Alex boards, and theoretically should have more than enough isolation for PureSignal. It should handle 100W. It takes 12V input and has a transistor switch for keying. This is early stage, and I'm just ordering Rev. A boards now. But I'm trying to see if there's enough interest to do a TAPR kit (all through-hole parts!) that would probably be in the $50 range. If you'd be interested, please drop a note off-list to jra at febo.com. 73, John From jbden at charter.net Tue Aug 26 12:47:31 2014 From: jbden at charter.net (John) Date: Tue, 26 Aug 2014 14:47:31 -0500 Subject: [hpsdr] AsRock SBC Message-ID: <53FCE453.8030503@charter.net> If some one is looking for a nice SBC, check out AsRock's line of j1900 mini-itx motherboards. I just buit one using memory and case I had on hand, for less than $200. It has built in dc-dc converter so it will use a netbook brick for power. Only uses about 10 Watts. Soon after I built it, they announced a new one using j2900 intel Pentium. I am not going to list all features, because they are on Asrock's site. John N4HXL From k5so at valornet.com Tue Aug 26 12:59:31 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Tue, 26 Aug 2014 13:59:31 -0600 Subject: [hpsdr] Timing Closure Field Guide Message-ID: All, In an effort to assist in making the timing closure tasks associated with OpenHPSDR firmware development less intimidating and easier for beginners to participate I have prepared a PDF document that describes a standardized procedure that I use for the task. The document may be downloaded from http://www.k5so.com/TimingClosureFieldGuide.pdf Please be aware that I do not claim to be an expert in this area and that the document may well have some errors and omissions; but I can guarantee that the document contains a decent sampling of the author?s personal bias. 73, Joe K5SO -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnlaur at gmail.com Tue Aug 26 13:27:22 2014 From: johnlaur at gmail.com (John Laur) Date: Tue, 26 Aug 2014 15:27:22 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53FCB91C.1090209@alphatronique.com> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> <53FCB91C.1090209@alphatronique.com> Message-ID: All, Thank you for the good discussion. My intention was not to focus too much on the Jetson discussion actually; I do know that if the code runs on Jetson I can happily build a small linux machine that will also run it, so nobody is "locking" anyone into any particular thing. I just think the Jetson is a low mark to aim for. If it can do a realtime 30mHz FFT, so can basically any current GPU. Even low power cards like the GeForce 750 Ti will run circles around it, while drawing 60W and costing less. I think anyone who has ever compiled up the fosphor plugin on GNU Radio has probably lamented not having that view available all the time. So I wont beat on Jetson any more. I just thought while we were on the subject of architectures it would be a good time to cut to the chase on the bandwidth problem. While I will agree with Hermann that SDR hardware (and the HDL features of HPSDR) seem to be changing as fast or faster than SDR software in recent months, I also think it ought to be the other way around. On the big list of SDR's from Wikipedia http://en.wikipedia.org/wiki/List_of_software-defined_radios I note only 2 devices use PCIe. I think the hardware is changing largely because of all the ways that developers are choosing to deal with the problems of interface constraints; hardware that can filter this amount of data at this datarate is neither easy nor cheap to engineer. There is no need to go to this length if you can just move all the data in the first place. But if the GPU architecture is the way forward, it's just silly to put an intermediate interface that requires a lot of HDL work in the way. For a direct sampling design the most future proof design possible is to make sure the hardware is at minimum capable of sending the raw ADC/DAC/Clock data in and out at full datarate to an attached device. IMO the reason working with the SoCKit hardware and Scotty's boards is probably so nice is because the interface from the FPGA to the software is basically transparent. (This is half speculation as I have a SoCKit that I have used quite a bit but have not yet put funds together for a board set from Scotty) There is no ethernet PHY and framing and protocol to get at the DDC data; the CPU just opens a device and starts reading. If That eliminates a lot of complexity. But you could easily plug his board set into a different dev kit like this http://www.altera.com/products/devkits/altera/kit-cyclone-v-gt.html and with some (admitted) effort you could make yourself a prototype PCIe HPSDR card right now that could do DMA transfers of ADC samples right into GPU memory with the same sort of ease. This is the beauty of a high speed interconnect standard. In this case it is HSMC, useful only within a certain scope, but it makes the point I think. A comment for Marc: From what I have seen Mini-PCIe is generally only ever offered with a x1 interface with the exception of MXM, so it makes more sense to adapt a PCIe card to the mini-PCIe form factor than vice versa; that way the card can be designed as a 4x or such. (It can always be allowed to fall back to 1x) Anyway to sum it all up neatly, a single integrated board like Hermes with a Cyclone V SoC part on board that can be used standalone or plugged in and used as a PCIe card would be pretty attractive HPSDR platform, I gotta say. 73, John KF5SAB From rcrewson at cinci.rr.com Tue Aug 26 15:21:16 2014 From: rcrewson at cinci.rr.com (Rob Crewson) Date: Tue, 26 Aug 2014 18:21:16 -0400 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: <001501cfc17c$0e1ef8d0$2a5cea70$@cinci.rr.com> Excellent document Joe, short , single path , to the point. I've nodded off many time trying to get thru the Altera docs. 73, RobC - VE3EW -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Joe Martin K5SO Sent: Tuesday, August 26, 2014 4:00 PM To: HPSDR list Subject: [hpsdr] Timing Closure Field Guide ***** High Performance Software Defined Radio Discussion List ***** From n9vv at wowway.com Tue Aug 26 15:27:06 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Tue, 26 Aug 2014 17:27:06 -0500 Subject: [hpsdr] AsRock SBC In-Reply-To: <53FCE453.8030503@charter.net> References: <53FCE453.8030503@charter.net> Message-ID: <53FD09BA.30505@wowway.com> Hi John, I also like to point my Update Scanner (checks webpages for chances every day) at this website: http://linuxgizmos.com/category/boards/ LinuxGizmos seems to have quite a wide variety of SBC's listed and updated on an almost hourly basis all the best, 73 de Ken N9VV On 8/26/2014 2:47 PM, John wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > If some one is looking for a nice SBC, check out AsRock's line of j1900 > mini-itx motherboards. > I just buit one using memory and case I had on hand, for less than $200. > It has built in dc-dc converter so it will use a netbook brick for > power. Only uses about 10 Watts. Soon after I built it, they announced a > new one using j2900 intel Pentium. I am not going to list all features, > because they are on Asrock's site. > John N4HXL > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From n9vv at wowway.com Tue Aug 26 15:27:06 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Tue, 26 Aug 2014 17:27:06 -0500 Subject: [hpsdr] AsRock SBC In-Reply-To: <53FCE453.8030503@charter.net> References: <53FCE453.8030503@charter.net> Message-ID: <53FD09BA.30505@wowway.com> Hi John, I also like to point my Update Scanner (checks webpages for chances every day) at this website: http://linuxgizmos.com/category/boards/ LinuxGizmos seems to have quite a wide variety of SBC's listed and updated on an almost hourly basis all the best, 73 de Ken N9VV On 8/26/2014 2:47 PM, John wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > If some one is looking for a nice SBC, check out AsRock's line of j1900 > mini-itx motherboards. > I just buit one using memory and case I had on hand, for less than $200. > It has built in dc-dc converter so it will use a netbook brick for > power. Only uses about 10 Watts. Soon after I built it, they announced a > new one using j2900 intel Pentium. I am not going to list all features, > because they are on Asrock's site. > John N4HXL > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From scotty at tonks.com Tue Aug 26 16:56:21 2014 From: scotty at tonks.com (Scott Cowling) Date: Tue, 26 Aug 2014 16:56:21 -0700 Subject: [hpsdr] Liva PC on sale at Newegg In-Reply-To: <53FCE453.8030503@charter.net> References: <53FCE453.8030503@charter.net> Message-ID: <7.0.1.0.2.20140826164456.0b4a5008@tonks.com> Hi all, Just saw this on the Newegg site (thanks to Ken, N9VV) and it looks very interesting. http://www.newegg.com/Product/Product.aspx?Item=N82E16856501007 While I have my share of low-power (and low-capability) PCs, this one looks especially intriguing. At only $132 including 2GB of RAM and 32GB eMMC drive, it is about as cheap as they come. Conduction cooled, Gigabit Ethernet, b/g/n WiFi, Bluetooth, dual monitor (HDMI + VGA) support, two USB ports (one 2.0, one 3.0) and a case; what more could you ask for? The special is only good through the end of August, so take a quick look if you are in the market for a new radio toy. Mine arrives Thursday. :-) We'll see if it has the guts to run GHPSDR3-Alex to put an HF1 receiver up on the QtRadio network! 73, Scotty WA2DFI From wb9qzb_groups at yahoo.com Tue Aug 26 17:29:19 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Tue, 26 Aug 2014 17:29:19 -0700 Subject: [hpsdr] Summer 2014 TAPR PSR Digital Communications Journal Available In-Reply-To: <1409098446.44945.YahooMailNeo@web140204.mail.bf1.yahoo.com> References: <1409098446.44945.YahooMailNeo@web140204.mail.bf1.yahoo.com> Message-ID: <1409099359.74958.YahooMailNeo@web140203.mail.bf1.yahoo.com> Summer 2014? TAPR PSR Digital Communications Journal? Available http://www.tapr.org/psr/psr126.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian13434 at yahoo.co.uk Wed Aug 27 02:23:23 2014 From: brian13434 at yahoo.co.uk (Brian D) Date: Wed, 27 Aug 2014 10:23:23 +0100 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: I've reverted to 4.1 firmware. The NaN problem has disappeared so it looks as if the angelia 4.2 firmware is the problem. Jae Stutzman wrote: I should have mentioned that I recently upgraded to 4.2 Angelia as well. So it could be either. I'll try downgrading back to 4.1 to see if that changes anything. I noticed it with TUN and it was reading out about 85W for each band. I was originally trying to find out if I was affected by the 10M winding issue. On Tue, Aug 26, 2014 at 4:54 AM, Brian D wrote: ***** High Performance Software Defined Radio Discussion List ***** Jae Stutzman wrote: > Is it just me or does the fwd pwr TX meter seem to be to be reading lower > than it should with this release? I was checking power outputs and it > seems to be about 15 watts lower than reality. Is this just me? I was > trying to adjust output power and that's when I realized it. I reset > databases just to be sure. I didn't notice this on 3.2.17. I haven't noticed it reading low but I've had several times it reading NaN for VSWR when tuning into the goood match of my test load. Not sure at this stage if it is the new version of HPSDR or my recent firmware upgrade to 4.2 (angelia). -- Brian D G3VGZ -- Brian D G3VGZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From k5so at valornet.com Wed Aug 27 06:10:22 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Wed, 27 Aug 2014 07:10:22 -0600 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: There are unfortunately subtle physical differences board-to-board and chip-to-chip on all of the hardware we use. These differences can sometimes result in different behavior of firmware on some boards. There are no features coded differently in the firmware versions mentioned. Minor signal-path timing differences between v4.1 and v4.2 are all that distinguish the two versions, in this particular case. If an earlier version of firmware works better for your particular board than does a later version then by all means use what works for you. 73, Joe K5SO On Aug 27, 2014, at 3:23 AM, Brian D wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I've reverted to 4.1 firmware. The NaN problem has disappeared so it looks > as if the angelia 4.2 firmware is the problem. > > > Jae Stutzman wrote: > I should have mentioned that I recently upgraded to 4.2 Angelia as well. So > it could be either. I'll try downgrading back to 4.1 to see if that changes > anything. I noticed it with TUN and it was reading out about 85W for each > band. I was originally trying to find out if I was affected by the 10M > winding issue. > > > On Tue, Aug 26, 2014 at 4:54 AM, Brian D wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Jae Stutzman wrote: > >> Is it just me or does the fwd pwr TX meter seem to be to be reading lower >> than it should with this release? I was checking power outputs and it >> seems to be about 15 watts lower than reality. Is this just me? I was >> trying to adjust output power and that's when I realized it. I reset >> databases just to be sure. I didn't notice this on 3.2.17. > > I haven't noticed it reading low but I've had several times it reading NaN > for VSWR when tuning into the goood match of my test load. Not sure at this > stage if it is the new version of HPSDR or my recent firmware upgrade to 4.2 > (angelia). > > > -- > Brian D > G3VGZ > From ad0es at ad0es.net Wed Aug 27 07:19:06 2014 From: ad0es at ad0es.net (AD0ES) Date: Wed, 27 Aug 2014 08:19:06 -0600 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: Hi, I have been slowly dipping my toes into the SDR pool, have a mercury rcvr setup functioning now. Excited about the direction new development is taking, especially in the area of moving more of the work from FPGA to a general class cpu/gpu. Next step for me is to setup with the tools necessary to write FPGA/gpu/openCL code. I spent some time on the Altera(?) site and went away totally confused. Are there tools available allowing one to design/write/compile FPGA code for these beasts without paying license fees or BEING CONNECTED to the net while using? I have no internet access at home and need a non-inet solution. If someone could provide a cookbook list of where/how to get the tools I believe it would get more people started down this path. tia, Steve AD0ES On Aug 26, 2014, at 1:59 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > In an effort to assist in making the timing closure tasks associated with OpenHPSDR firmware development less intimidating and easier for beginners to participate I have prepared a PDF document that describes a standardized procedure that I use for the task. The document may be downloaded from From k5so at valornet.com Wed Aug 27 07:51:49 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Wed, 27 Aug 2014 08:51:49 -0600 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: <8D51197B-0E5F-4B20-86A6-AB8D93FB0713@valornet.com> Hi Steve, With regard to the necessary FGPA tools, you need only the free Quartus II program download from: https://www.altera.com/download/sw/dnl-sw-index.jsp at the bottom of the page is a window that allows you to select to download any version of Quartus II from v2.2 to v14.0. As you are working with Atlas-based boards I would suggest that the latest version for you work with should be v13.0 as later versions do not support the Cyclone II FPGA used in Penelope and the latest v14.0 does not support the Cyclone III FPGA used in Mercury. Quartus II will run just fine without being connect to the internet. You will receive a startup message that Quartus II can?t get to the Quartus website to check for updates but simply close the window and things will be fine. 73, Joe K5SO On Aug 27, 2014, at 8:19 AM, AD0ES wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi, > > I have been slowly dipping my toes into the SDR pool, have a mercury rcvr setup functioning now. Excited about the > direction new development is taking, especially in the area of moving more of the work from FPGA to a general class > cpu/gpu. Next step for me is to setup with the tools necessary to write FPGA/gpu/openCL code. > > I spent some time on the Altera(?) site and went away totally confused. Are there tools available allowing one to > design/write/compile FPGA code for these beasts without paying license fees or BEING CONNECTED to the net while using? > I have no internet access at home and need a non-inet solution. > > If someone could provide a cookbook list of where/how to get the tools I believe it would get more people started down > this path. > > tia, > Steve AD0ES > From wb9qzb_groups at yahoo.com Wed Aug 27 07:47:34 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Wed, 27 Aug 2014 07:47:34 -0700 Subject: [hpsdr] DCC Proceedings Abstracts Announced - 2014 ARRL/TAPR Digital Communications Conference Austin, TX September 5-7, 2014 In-Reply-To: <1409150515.91658.YahooMailNeo@web140204.mail.bf1.yahoo.com> References: <1409150515.91658.YahooMailNeo@web140204.mail.bf1.yahoo.com> Message-ID: <1409150854.72388.YahooMailNeo@web140201.mail.bf1.yahoo.com> http://www.tapr.org/pub_dcc33.html DCC Proceedings Abstracts: 33rd ARRL and TAPR Digital Communications Conference September 5-7, 2014 ________________________________ High-Speed Wireless Networking in the UHF and Microwave Bands? by?David Bern, W2LNX?and?Keith Elkin, KB3TCB Abstract:?This paper discusses building an amateur radio wireless network using commercial off the shelf wireless networking equipment that is currently available. As an example, four Ubiquiti NanoStation M3 3.4 GHz digital radios are used to assemble a demonstration network of two wireless network links that operate on two different frequencies. In conclusion, the paper invites the amateur radio community to build a nationwide highspeed amateur radio wireless backbone network to connect all local amateur radio area community wireless networks. Proceedings Paper Clarifying the Amateur Bell 202 Modem? by?Kenneth W. Finnegan, W6KWF?and?Bridget Benson, PhD The Stream Control Transmission Protocol (SCTP) and Its Potential for Amateur Radio? by?Eduardo Gonzalez?,?Dr Stan McClellan?and?Dr Wuxu Peng SDR-based DATV-Express Exciter for Digital-ATV? by?Ken Konechy, W6HHC A Radioteletype Over-Sampling Software Decoder for Amateur Radio? by?Joseph J. Roby, Jr, K0JJR An HF Frequency-Division Multiplex (FDM) Modem? by?Steven Sampson, K5OKC Modulation - Demodulation Software Radio? by?Alex Schwarz VE7DXW?and?Guy Roels ON6MU Installing a LIF port into the FT-950 transceiver? by?Alex Schwarz, VE7DXW Installing a LIF port into the IC-756ProIII transceiver? by?Alex Schwarz, VE7DXW The European HAMNET - A Large Scale High Speed Radio Network? by?Jann Traschewski, DG8NGN Implementation of Basic Analog and Digital Modulation Schemes using a SDR Platform? by?Jose M. Valencia?and?Omar H. Longoria -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjablonski at att.net Wed Aug 27 11:06:22 2014 From: bjablonski at att.net (Barry Jablonski) Date: Wed, 27 Aug 2014 14:06:22 -0400 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: <53FE1E1E.6050304@att.net> Hi Steve. Here is a link to a PDF of Altera's "Intro to Quartus II": www.altera.com/literature/manual/intro_to_quartus2.pdf Hope it helps. Barry WB2ZXJ From scotty at tonks.com Thu Aug 28 13:43:06 2014 From: scotty at tonks.com (Scott Cowling) Date: Thu, 28 Aug 2014 13:43:06 -0700 Subject: [hpsdr] Success with GNURadio on LIVA PC! In-Reply-To: <53FE1E1E.6050304@att.net> References: <53FE1E1E.6050304@att.net> Message-ID: <7.0.1.0.2.20140828130549.056c7120@tonks.com> Hi all, This is not strictly HPSDR related, but I thought that most would be interested is the SDR capabilities of the ECS LIVA PC that is on sale at Newegg for $132 through Friday. I got the LIVA on Wednesday and assembled it. (Be careful with those little MMCX connectors for the WiFi antenna. I broke one of them and had to repair it, which was not fun.) I installed Ubuntu 14.04 from a USB flash drive, then downloaded and ran the GNURadio install script for version 3.7.4. Then I downloaded the SDRstick source block and followed the instructions to build and install it (only about 6 steps). I plugged in my HF1 and BeMicroSDK hardware to the USB port (for power) and the GigE port (for data). Amazingly, it came right up! The sample AM receiver flowgraph works, and at 384K bandwidth I can hear (and see) AM broadcast stations with no dropouts. This is pretty exciting for such a small, low-power PC! When I go to 1.25MHz bandwidth, the receiver still works, but the PC just can't keep the graphics on the screen updated. I haven't tweaked any priorities yet, but it looks like 1.25MHz is a bit too much for this "little PC that could"! I will bring this setup to DCC next weekend to demo. 73, Scotty WA2DFI From g4hup at btinternet.com Thu Aug 28 15:01:06 2014 From: g4hup at btinternet.com (dave powis) Date: Thu, 28 Aug 2014 23:01:06 +0100 Subject: [hpsdr] FS - Hermes set-up Message-ID: <1409263266.99171.YahooMailNeo@web87703.mail.ir2.yahoo.com> For sale - my Hermes set up, comprising: TAPR Hermes mounted in Hammond case, with additional chip heatsink and external power connector N8UR breakout board for J16 Munin PA kit with heatsink and Hammond case (not assembled). Looking for ?800.? Shipping to be discussed - preference to UK sale. Also available Alex Tx/Rx Filter set in housing? - assembled, with cables Looking for ?300. Shipping to be discussed - preference to UK sale. Please contact me off-list at g4hup-at-btinternet-dot-com Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From lstoskopf at cox.net Thu Aug 28 21:05:17 2014 From: lstoskopf at cox.net (lstoskopf at cox.net) Date: Fri, 29 Aug 2014 0:05:17 -0400 Subject: [hpsdr] Success with GNURadio on LIVA PC! In-Reply-To: Message-ID: <20140829000517.QTPFP.168732.imail@eastrmwml107> Great. Some of us did the Kickstarter thing to have the talks put on HamTV (I think). Hit him up for a quick segment on your setup and operation. Awaiting the new AC9 board. N0UU From jkelly at verizon.net Fri Aug 29 03:07:06 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 29 Aug 2014 06:07:06 -0400 Subject: [hpsdr] WTB Funcube Dongle Pro Message-ID: <0NB2007XYC3WYBA0@vms173015.mailsrvcs.net> Send email to: K2SDR at verizon.net Jeff From wb9qzb_groups at yahoo.com Fri Aug 29 12:30:21 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Fri, 29 Aug 2014 12:30:21 -0700 Subject: [hpsdr] ARRL/TAPR DCC Speaker Schedule Announced, Austin, TX, 9/5 - 9/7/14 (Walk-In Registrations at DCC Welcome) In-Reply-To: <8D191D64470CED4-1EF4-448A@webmail-vd010.sysops.aol.com> References: <1409340051.42235.YahooMailNeo@web140202.mail.bf1.yahoo.com> <8D191D5E158017D-1EF4-443D@webmail-vd010.sysops.aol.com> <8D191D64470CED4-1EF4-448A@webmail-vd010.sysops.aol.com> Message-ID: <1409340621.78960.YahooMailNeo@web140201.mail.bf1.yahoo.com> DCC Speaker Schedule Announced 2014 ARRL/TAPR Digital Communications Conference Austin, TX September 5 - 7, 2014 http://www.tapr.org/pdf/DCC_2014_Schedule_2014-08-27.pdf Register for the DCC Walk-in registrations at DCC are very welcome. Online Registration Form https://www.tapr.org/dccregistration.php Pre-registration will close on August 30th to allow the office staff to complete preparations (print badges and stuff envelopes) and travel to the conference. Use of the on-line registration form after August 30th is encouraged, as it will save time at the registration desk filling in hard copy forms and wait for credit card processing.. Tucson Amateur Packet Radio Phone: (972) 671-TAPR (8277) Contact TAPR Office: http://www.tapr.org/inforequest.php -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkelly at verizon.net Fri Aug 29 15:17:12 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 29 Aug 2014 18:17:12 -0400 Subject: [hpsdr] WTB Funcube Dongle Pro In-Reply-To: <0NB2007XYC3WYBA0@vms173015.mailsrvcs.net> References: <0NB2007XYC3WYBA0@vms173015.mailsrvcs.net> Message-ID: <594C7EC51FA641619B6FBBD3FBAEFBAE@JeffPC> Thank you got one. Jeff -----Original Message----- From: Jeff Kelly Sent: Friday, August 29, 2014 6:07 To: hpsdr at openhpsdr.org Subject: [hpsdr] WTB Funcube Dongle Pro ***** High Performance Software Defined Radio Discussion List ***** Send email to: K2SDR at verizon.net Jeff _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From w5wc at windstream.net Fri Aug 29 16:54:12 2014 From: w5wc at windstream.net (Doug Wigley) Date: Fri, 29 Aug 2014 18:54:12 -0500 Subject: [hpsdr] PowerSDR/OpenHPSDR mRX PS v3.2.19 released Message-ID: <00ad01cfc3e4$88b755f0$9a2601d0$@net> All, PowerSDR/OpenHPSDR mRX PS v3.2.19 has been released. Bug fixes added for the following problems: - APF text field in the VFOA window masked part of the VHF frequency. - Unable to use the DJ Console with CTUN enabled. Added colors to the diversity "Enable" button. Green = ON, Red = OFF. No database reset required! This release can be downloaded from the openhpsdr.org website. http://openhpsdr.org/download.php 73, Doug W5WC From mlalonde at alphatronique.com Fri Aug 29 17:29:08 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Fri, 29 Aug 2014 20:29:08 -0400 Subject: [hpsdr] Success with GNURadio on LIVA PC! In-Reply-To: <7.0.1.0.2.20140828161242.05444838@tonks.com> References: <53FE1E1E.6050304@att.net> <7.0.1.0.2.20140828130549.056c7120@tonks.com> <53FFA0FB.2090201@alphatronique.com> <7.0.1.0.2.20140828161242.05444838@tonks.com> Message-ID: <54011AD4.2080806@alphatronique.com> Hi first that really small PC ! next it require a "UEFI" bootable USB key AND a 64Bit win 8.1 for work anything else fail to boot and/or install ,i lost big part of my day figure it ... i make work whit decent performance of 2 or less decoding WSJT-X (not forget the NTP server) JT65HF-109 one that not work JT65-HF HB9HQX remain on "receiving" so whit my KX3 i made nice portable JT65 setup and\or monitor for 6M opening 73 .. Marc L VE2OLM On 28/08/2014 7:13 PM, Scott Cowling wrote: > Hi Marc, > > Sounds like a good use for one! I would like to hear about your setup > when you get it running. > > 73, > Scotty WA2DFI > > At 17:36 2014-08-28 -0400, you wrote: >> Hi >> >> Thank i have order one for try to use it for monitor 6M Band opening >> whit JT65A >> >> 73 >> Marc VE2OLM >> >> On 28/08/2014 4:43 PM, Scott Cowling wrote: >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> Hi all, >>> >>> This is not strictly HPSDR related, but I thought that most would be >>> interested is the SDR capabilities of the ECS LIVA PC that is on >>> sale at Newegg for $132 through Friday. >>> >>> I got the LIVA on Wednesday and assembled it. (Be careful with those >>> little MMCX connectors for the WiFi antenna. I broke one of them and >>> had to repair it, which was not fun.) >>> >>> I installed Ubuntu 14.04 from a USB flash drive, then downloaded and >>> ran the GNURadio install script for version 3.7.4. Then I downloaded >>> the SDRstick source block and followed the instructions to build and >>> install it (only about 6 steps). >>> >>> I plugged in my HF1 and BeMicroSDK hardware to the USB port (for >>> power) and the GigE port (for data). >>> >>> Amazingly, it came right up! The sample AM receiver flowgraph works, >>> and at 384K bandwidth I can hear (and see) AM broadcast stations >>> with no dropouts. This is pretty exciting for such a small, >>> low-power PC! >>> >>> When I go to 1.25MHz bandwidth, the receiver still works, but the PC >>> just can't keep the graphics on the screen updated. I haven't >>> tweaked any priorities yet, but it looks like 1.25MHz is a bit too >>> much for this "little PC that could"! >>> >>> I will bring this setup to DCC next weekend to demo. >>> >>> 73, >>> Scotty WA2DFI >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: >>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > From aa8k73 at gmail.com Fri Aug 29 19:31:47 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 29 Aug 2014 22:31:47 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/30 Message-ID: <54013793.3030108@gmail.com> The 30/Aug TeamSpeak mp3 (67 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3513 > or < http://www.hamsdr.com/dnld.aspx > Only silence truncation editing was done on this recording. From dc6ny at gmx.de Sun Aug 31 02:49:41 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Sun, 31 Aug 2014 11:49:41 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> <53FCB91C.1090209@alphatronique.com> Message-ID: <000001cfc500$e38379b0$aa8a6d10$@de> Hi, I read a topical notification of the USB Promoter Group (HP, Intel, MS, Renesas Elec, TI ) that USB 3.1 will be already available end of 2014. This smart (cheap) interface could be one option for a fast 10 Gbit/s connection of future broadband DDC/DUC hardware and versatile computer architectures. I think it's certainly worth to watch further progress and market. 73, Helmut, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von John Laur Gesendet: Dienstag, 26. August 2014 22:27 An: HPSDR list Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** All, Thank you for the good discussion. My intention was not to focus too much on the Jetson discussion actually; I do know that if the code runs on Jetson I can happily build a small linux machine that will also run it, so nobody is "locking" anyone into any particular thing. I just think the Jetson is a low mark to aim for. If it can do a realtime 30mHz FFT, so can basically any current GPU. Even low power cards like the GeForce 750 Ti will run circles around it, while drawing 60W and costing less. I think anyone who has ever compiled up the fosphor plugin on GNU Radio has probably lamented not having that view available all the time. So I wont beat on Jetson any more. I just thought while we were on the subject of architectures it would be a good time to cut to the chase on the bandwidth problem. While I will agree with Hermann that SDR hardware (and the HDL features of HPSDR) seem to be changing as fast or faster than SDR software in recent months, I also think it ought to be the other way around. On the big list of SDR's from Wikipedia http://en.wikipedia.org/wiki/List_of_software-defined_radios I note only 2 devices use PCIe. I think the hardware is changing largely because of all the ways that developers are choosing to deal with the problems of interface constraints; hardware that can filter this amount of data at this datarate is neither easy nor cheap to engineer. There is no need to go to this length if you can just move all the data in the first place. But if the GPU architecture is the way forward, it's just silly to put an intermediate interface that requires a lot of HDL work in the way. For a direct sampling design the most future proof design possible is to make sure the hardware is at minimum capable of sending the raw ADC/DAC/Clock data in and out at full datarate to an attached device. IMO the reason working with the SoCKit hardware and Scotty's boards is probably so nice is because the interface from the FPGA to the software is basically transparent. (This is half speculation as I have a SoCKit that I have used quite a bit but have not yet put funds together for a board set from Scotty) There is no ethernet PHY and framing and protocol to get at the DDC data; the CPU just opens a device and starts reading. If That eliminates a lot of complexity. But you could easily plug his board set into a different dev kit like this http://www.altera.com/products/devkits/altera/kit-cyclone-v-gt.html and with some (admitted) effort you could make yourself a prototype PCIe HPSDR card right now that could do DMA transfers of ADC samples right into GPU memory with the same sort of ease. This is the beauty of a high speed interconnect standard. In this case it is HSMC, useful only within a certain scope, but it makes the point I think. A comment for Marc: From what I have seen Mini-PCIe is generally only ever offered with a x1 interface with the exception of MXM, so it makes more sense to adapt a PCIe card to the mini-PCIe form factor than vice versa; that way the card can be designed as a 4x or such. (It can always be allowed to fall back to 1x) Anyway to sum it all up neatly, a single integrated board like Hermes with a Cyclone V SoC part on board that can be used standalone or plugged in and used as a PCIe card would be pretty attractive HPSDR platform, I gotta say. 73, John KF5SAB _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From k5so at valornet.com Sun Aug 31 09:29:55 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 31 Aug 2014 10:29:55 -0600 Subject: [hpsdr] Orion/ANAN-200D Orion_v2.7 firmware package release Message-ID: <4571643A-37A2-4780-97D1-3D70793B24C8@valornet.com> All, Orion_v2.7 firmware package is available for download from http://www.k5so.com/HPSDR_downloads.html This version of firmware fixes a failure to key an external amplifiler via the PTT output connector when keyed via the external PTT input pin of the accessory jack when in CW mode and improper behavior of non-breakin CW PTT functionality. I have alerted Phil and Abhi that this issue, corrected earlier in Angelia firmware, exists in any of our firmware designs that have implemented CW generated withing the FPGA, including Hermes and Atlas-based systems. It is my expectation that they will shortly release new versions of their respective firmware packages to include this fix which has now already been applied to the Angelia and Orion firmware. 73, Joe K5SO From wb4gcs at wb4gcs.org Sun Aug 31 11:29:21 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Sun, 31 Aug 2014 14:29:21 -0400 Subject: [hpsdr] Multiple Metis on one Ethernet Message-ID: <54036981.2020709@wb4gcs.org> All: Have one HPSDR running. Building the second. FOr now, mercury is set to obtain IP address via DHCP. Any problems putting the second one on the network to update firmware in my very old mercury and penny boards? Thanks & 73, Jim wb4gcs at amsat.org --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From beford at myfairpoint.net Sun Aug 31 13:01:55 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Sun, 31 Aug 2014 16:01:55 -0400 Subject: [hpsdr] Munin amp kits for sale Message-ID: I purchased two complete kits for Munin when they were offered by Don, K3DLW, but have not built either yet. I would be willing to sell both for what I paid, plus postage. This also includes the PC boards , all components, heat sinks and copper heat spreaders. That would come to $170 each total, including Priority mail to your US address. Check, Money Order, or PayPal would be fine. Please reply off-list. mycall at arrl dot net Thanks, Bruce/N1RX -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 13:30:30 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 15:30:30 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 Message-ID: After about 3 hours worth of work and a few workarounds, I made my first QSO on 20 meters under Linux! I used MonoDevelop as the IDE for the C# KISS solution. I had to make a couple of changes for the P/Invokes of the fftw3f library and some of the Networking calls, which are still not implemented within the Mono CLR. The performance is quite good, I'll compare it to my Windows box to see the differences. Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. I'll document my changes and the dependencies that I installed to make it work soon. Thanks everyone for the welcome and thanks to the authors of KISS Konsole for making the porting easy :) 73, Jae - K5JAE -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 13:36:38 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 15:36:38 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: The link should not have the following '.' at the end. Here it is again: http://i.imgur.com/AsJ4pSE.png On Sun, Aug 31, 2014 at 3:30 PM, Jae Stutzman wrote: > After about 3 hours worth of work and a few workarounds, I made my first > QSO on 20 meters under Linux! > > I used MonoDevelop as the IDE for the C# KISS solution. I had to make a > couple of changes for the P/Invokes of the fftw3f library and some of the > Networking calls, which are still not implemented within the Mono CLR. The > performance is quite good, I'll compare it to my Windows box to see the > differences. > > Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. > I'll document my changes and the dependencies that I installed to make it > work soon. > > Thanks everyone for the welcome and thanks to the authors of KISS Konsole > for making the porting easy :) > > > 73, > > Jae - K5JAE > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.frohne at wallawalla.edu Sun Aug 31 15:12:51 2014 From: rob.frohne at wallawalla.edu (Rob Frohne) Date: Sun, 31 Aug 2014 14:12:51 -0800 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: That's neat Jae! 73, Rob KL7NA On August 31, 2014 12:36:38 PM AKDT, Jae Stutzman wrote: >***** High Performance Software Defined Radio Discussion List ***** > > > >------------------------------------------------------------------------ > >The link should not have the following '.' at the end. Here it is >again: >http://i.imgur.com/AsJ4pSE.png > > > >On Sun, Aug 31, 2014 at 3:30 PM, Jae Stutzman >wrote: > >> After about 3 hours worth of work and a few workarounds, I made my >first >> QSO on 20 meters under Linux! >> >> I used MonoDevelop as the IDE for the C# KISS solution. I had to make >a >> couple of changes for the P/Invokes of the fftw3f library and some of >the >> Networking calls, which are still not implemented within the Mono >CLR. The >> performance is quite good, I'll compare it to my Windows box to see >the >> differences. >> >> Here is a link to a screenshot of how it looks: >http://imgur.com/AsJ4pSE. >> I'll document my changes and the dependencies that I installed to >make it >> work soon. >> >> Thanks everyone for the welcome and thanks to the authors of KISS >Konsole >> for making the porting easy :) >> >> >> 73, >> >> Jae - K5JAE >> >> >> >> > > >------------------------------------------------------------------------ > >_______________________________________________ >HPSDR Discussion List >To post msg: hpsdr at openhpsdr.org >Subscription help: >http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >HPSDR web page: http://openhpsdr.org >Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wb4gcs at wb4gcs.org Sun Aug 31 14:57:25 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Sun, 31 Aug 2014 17:57:25 -0400 Subject: [hpsdr] Trouble updating Mercury firmware Message-ID: <54039A45.8020804@wb4gcs.org> All: I am finally assembling the system I purchased in pieces long ago from TAPR. I have successfully updated Metis firmware to the latest. I have installed J1 in Metis to put it in bootloader mode. I have installed J7 (last JTAG) jumper on Mercury. Running HPSDRProgrammer V2 version 2.0.4.0 All the LEDs on Mercury that the manual says should be lit are. When I click DISCOVER, Mercury is not found, and I get an error message telling me to "Make sure the correct interface is attached. There is only one interface -- the ethernet interface on the computer. Any suggestions?? Thanks & 73, Jim wb4gcs at amsat.org --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From k5jae at stutzman.net Sun Aug 31 15:54:22 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 17:54:22 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: On a whim, I thought I might try the Jetson TK1 board with mono/kiss konsole. After working out the dependencies, it appears to run OK (I haven't transmitted yet). Anything beyond 96000 sample rate will give audio distortion on the receive. If I choose 192000 and then select NR, it really goes off the rails. Keep in mind that this is completely running within the ARM hard float CPU, which is using the original libfftw3 FFT library. Utilizing a CUDA optimized FFT library would probably give a lot more headroom. Both the spectrum and waterfall displays are ok with some slight hiccup that correspond to audio blips. 73, Jae - K5JAE On Sun, Aug 31, 2014 at 5:12 PM, Rob Frohne wrote: > That's neat Jae! > > 73, > Rob > KL7NA > > On August 31, 2014 12:36:38 PM AKDT, Jae Stutzman > wrote: >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> The link should not have the following '.' at the end. Here it is again: >> http://i.imgur.com/AsJ4pSE.png >> >> >> >> On Sun, Aug 31, 2014 at 3:30 PM, Jae Stutzman wrote: >> >>> After about 3 hours worth of work and a few workarounds, I made my first >>> QSO on 20 meters under Linux! >>> >>> I used MonoDevelop as the IDE for the C# KISS solution. I had to make a >>> couple of changes for the P/Invokes of the fftw3f library and some of the >>> Networking calls, which are still not implemented within the Mono CLR. The >>> performance is quite good, I'll compare it to my Windows box to see the >>> differences. >>> >>> Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. >>> I'll document my changes and the dependencies that I installed to make it >>> work soon. >>> >>> Thanks everyone for the welcome and thanks to the authors of KISS >>> Konsole for making the porting easy :) >>> >>> >>> 73, >>> >>> Jae - K5JAE >>> >>> >>> >>> >> ------------------------------ >> >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Sun Aug 31 16:09:32 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 31 Aug 2014 17:09:32 -0600 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: <6B339E1F-4D1A-4AF4-9404-386B050807B3@valornet.com> Congratulations, Jae! That?s excellent news! I have just this past Thursday assembled a new computer system to allow me to begin exploring Linux. I have installed Ubuntu, Synaptic, Mono-complete, MonoDevelop and am anxious to get rolling on porting some of my Windows C# radio astronomy apps that I have written over to Linux. I am ecstatic to hear that you have KISS ported over now (in such a brief time too!!) and I am very interested to see how you did it. Also, I too have a strong interest in porting PowerSDR over to Linux and I have heard of your vast experience in such porting activities. I am quite excited to learn of any progress that you make there so please do give us updates as to your progress. I, naively of course, intended to give it a try myself as soon as I gain more familiarity with Linux, and Mono in particular. I currently use Visual Studio 2013 to make mods to the PowerSDR code from time to time but I?m not a professional programmer and barely squeak along with VS to be truthful; but I?m continuing to learn all the time and am getting more proficient, I hope. I am a complete newbie with respect to Linux so please don?t be overly brief in your ?how to? descriptions or they?ll go completely over my head for sure. Thanks, and congrats again! 73, Joe K5SO From g3vbv at blueyonder.co.uk Sun Aug 31 16:20:51 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 01 Sep 2014 00:20:51 +0100 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: <5403ADD3.2020209@blueyonder.co.uk> Neat. Back in May 2013 I posted the following but didn't get a reply. This was using the .exe under Crossover Office. ------------------------------------------------------------------------------------ For curiosity value mainly. Just seeing if anyone has an idea what's happening. Appending screenshots exceeds the allowed email limit. I select HERMES and when I click ON I get a string of these messages, it sees Hermes on 192.168.10.77 then the 127.12.34.56 Metis stuff, Metis is not selected, only Hermes with 2.4 firmware. Found a Metis/Hermes/Griffin. Checking whether it qualifies Metis IP from IP Header = 192.168.10.77 Metis MAC address from payload = 00-04-A3-6A-21-BE Not on subnet of host adapter! Adapter IP 127.12.34.56, Adapter mask 255.255.255.255 No data from Port = Ready to receive.... raw Discovery data = EF-FE-02-00-04-A3-6A-21-BE-18-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 -01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 ----------------------------------------------------------------------------------------------------------------------- 73 ... Sid. On 31/08/14 21:30, Jae Stutzman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > After about 3 hours worth of work and a few workarounds, I made my > first QSO on 20 meters under Linux! > > I used MonoDevelop as the IDE for the C# KISS solution. I had to make > a couple of changes for the P/Invokes of the fftw3f library and some > of the Networking calls, which are still not implemented within the > Mono CLR. The performance is quite good, I'll compare it to my Windows > box to see the differences. > > Here is a link to a screenshot of how it looks: > http://imgur.com/AsJ4pSE. I'll document my changes and the > dependencies that I installed to make it work soon. > > Thanks everyone for the welcome and thanks to the authors of KISS > Konsole for making the porting easy :) > > > 73, > > Jae - K5JAE > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 16:25:48 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 18:25:48 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: <6B339E1F-4D1A-4AF4-9404-386B050807B3@valornet.com> References: <6B339E1F-4D1A-4AF4-9404-386B050807B3@valornet.com> Message-ID: Joe, This is obviously a proof of concept at this point. Some of the issues I experienced years ago with Mono and WinForms are still there. Namely, rendering issues. On Windows, WinForms is a thin wrapper on top of native Windows libraries. On Linux, the Mono team wrote the entire library in managed code before diving into the native X Windows UI layer. What I find is that initial widget rendering is a bit slow and then size and location of widgets don't always render correctly. However, the UI seems usable. I'll definitely relay my findings to this group. More to follow :) 73, Jae - K5JAE On Aug 31, 2014 6:09 PM, "Joe Martin K5SO" wrote: > Congratulations, Jae! That?s excellent news! > > I have just this past Thursday assembled a new computer system to allow me > to begin exploring Linux. I have installed Ubuntu, Synaptic, > Mono-complete, MonoDevelop and am anxious to get rolling on porting some of > my Windows C# radio astronomy apps that I have written over to Linux. I am > ecstatic to hear that you have KISS ported over now (in such a brief time > too!!) and I am very interested to see how you did it. > > Also, I too have a strong interest in porting PowerSDR over to Linux and I > have heard of your vast experience in such porting activities. I am quite > excited to learn of any progress that you make there so please do give us > updates as to your progress. I, naively of course, intended to give it a > try myself as soon as I gain more familiarity with Linux, and Mono in > particular. I currently use Visual Studio 2013 to make mods to the > PowerSDR code from time to time but I?m not a professional programmer and > barely squeak along with VS to be truthful; but I?m continuing to learn all > the time and am getting more proficient, I hope. > > I am a complete newbie with respect to Linux so please don?t be overly > brief in your ?how to? descriptions or they?ll go completely over my head > for sure. > > Thanks, and congrats again! > > 73, Joe K5SO > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 17:03:01 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 19:03:01 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: <5403ADD3.2020209@blueyonder.co.uk> Message-ID: Sid, I've only used CrossOver for a couple of things. There is a big difference to running and exe within CX and Mono. First, CX is a reimplementation of win32/64 native libraries under Linux and libc. It intends to allow win apps to run as though they are on windows. This means you install .NET on top of CX to run C# apps. It has been moderately successful and a huge undertaking! Mono, on the other hand is a reimplementation of the CLR/CLI. It doesn't bring in any win32/64 APIs and is a clean room implementation. It would be analogous to the JVM running on Linux vs running on Windows, except that MS didn't provide a Linux version so the OSS community wrote it themselves. I view CX as a compromise to bring windows applications to Linux. I view Mono as a first class development and runtime environment where Linux apps can be made and executed. That said. I like cross platform development. With careful consideration an app can look and run as if native on many different platforms. As far as your log, I'm not sure what was going on! Except it looks like it had something to do with the network interface. 73, Jae > On Aug 31, 2014 6:20 PM, "Sid Boyce" wrote: >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> >> Neat. >> Back in May 2013 I posted the following but didn't get a reply. This was using the .exe under Crossover Office. >> ------------------------------------------------------------------------------------ >> For curiosity value mainly. >> Just seeing if anyone has an idea what's happening. >> Appending screenshots exceeds the allowed email limit. >> >> I select HERMES and when I click ON I get a string of these messages, it sees Hermes on 192.168.10.77 then the 127.12.34.56 Metis stuff, Metis is not selected, only Hermes with 2.4 firmware. >> >> Found a Metis/Hermes/Griffin. Checking whether it qualifies >> Metis IP from IP Header = 192.168.10.77 >> Metis MAC address from payload = 00-04-A3-6A-21-BE >> Not on subnet of host adapter! Adapter IP 127.12.34.56, Adapter mask 255.255.255.255 >> No data from Port = >> Ready to receive.... >> raw Discovery data = EF-FE-02-00-04-A3-6A-21-BE-18-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 >> -01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 >> ----------------------------------------------------------------------------------------------------------------------- >> 73 ... Sid. >> >> On 31/08/14 21:30, Jae Stutzman wrote: >>> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> >>> >>> After about 3 hours worth of work and a few workarounds, I made my first QSO on 20 meters under Linux! >>> >>> I used MonoDevelop as the IDE for the C# KISS solution. I had to make a couple of changes for the P/Invokes of the fftw3f library and some of the Networking calls, which are still not implemented within the Mono CLR. The performance is quite good, I'll compare it to my Windows box to see the differences. >>> >>> Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. I'll document my changes and the dependencies that I installed to make it work soon. >>> >>> Thanks everyone for the welcome and thanks to the authors of KISS Konsole for making the porting easy :) >>> >>> >>> 73, >>> >>> Jae - K5JAE >>> >>> >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> >> >> -- >> 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 >> >> >> _______________________________________________ >> >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wp4o at tampabay.rr.com Sun Aug 31 17:42:30 2014 From: wp4o at tampabay.rr.com (ed) Date: Sun, 31 Aug 2014 20:42:30 -0400 Subject: [hpsdr] anan 100 forsale Message-ID: <000001cfc57d$9cad2310$d6076930$@tampabay.rr.com> Selling my extra ANAN 100 has new Smps regulator and VCXO Runs very cool. E mail me if interested. Thanks and 73, Ed KK4x, Tampa Florida -------------- next part -------------- An HTML attachment was scrubbed... URL: From kv0s.dave at gmail.com Sun Aug 31 18:15:24 2014 From: kv0s.dave at gmail.com (Dave Larsen) Date: Sun, 31 Aug 2014 20:15:24 -0500 Subject: [hpsdr] Trouble updating Mercury firmware In-Reply-To: <54039A45.8020804@wb4gcs.org> References: <54039A45.8020804@wb4gcs.org> Message-ID: Jim Almost right There are two programs, HPSDRProgrammer V2 only talks to boards with ethernet sockets and does not need the j1 jumper but it will not program through a JTAG port. the second program HPSDRBootloader is for use in the Bootloader mode as you specified. If you follow your steps, EXCEPT use HPSDRBootloader it should work.. HPSDRBootloader uses the pcap library, the J1 jumper and a raw Ethernet packets and cane be used as a JTAG programmer for boards with no Ethernet connector. HPSDRProgrammer V2 is use UDP, no jumper and old firmware newer that 2.3, This is convenients for update firmware without opening the box. But if the old firmware is broke it will not work. PS. HPSDRProgrammer V1.6 does both tasks but people got confused different problem and what part of the program when with each task. Dave KV0S HPSDRProgrammer V2 and HPSDRBootloader Programmer and Maintainer On Sun, Aug 31, 2014 at 4:57 PM, Jim Sanford wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All: > I am finally assembling the system I purchased in pieces long ago from > TAPR. > > I have successfully updated Metis firmware to the latest. > > I have installed J1 in Metis to put it in bootloader mode. > > I have installed J7 (last JTAG) jumper on Mercury. > > Running HPSDRProgrammer V2 version 2.0.4.0 > > All the LEDs on Mercury that the manual says should be lit are. > > When I click DISCOVER, Mercury is not found, and I get an error message > telling me to "Make sure the correct interface is attached. There is only > one interface -- the ethernet interface on the computer. > > Any suggestions?? > > Thanks & 73, > Jim > wb4gcs at amsat.org > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/ > listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- KV0S - Dave Larsen Columbia, MO, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: From wb4gcs at wb4gcs.org Sun Aug 31 18:21:11 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Sun, 31 Aug 2014 21:21:11 -0400 Subject: [hpsdr] Trouble updating Mercury firmware In-Reply-To: References: <54039A45.8020804@wb4gcs.org> Message-ID: <5403CA07.2010802@wb4gcs.org> That did it, thanks!!!!! 73, Jim wb4gcs at amsat.org On 8/31/2014 9:15 PM, Dave Larsen wrote: > Jim > > Almost right > > There are two programs, HPSDRProgrammer V2 only talks to boards with > ethernet sockets and does not need the j1 jumper but it will not > program through a JTAG port. > > the second program HPSDRBootloader is for use in the Bootloader mode > as you specified. If you follow your steps, EXCEPT use > HPSDRBootloader it should work.. > > HPSDRBootloader uses the pcap library, the J1 jumper and a raw > Ethernet packets and cane be used as a JTAG programmer for boards with > no Ethernet connector. > > HPSDRProgrammer V2 is use UDP, no jumper and old firmware newer that > 2.3, This is convenients for update firmware without opening the box. > But if the old firmware is broke it will not work. > > > PS. HPSDRProgrammer V1.6 does both tasks but people got confused > different problem and what part of the program when with each task. > > Dave KV0S HPSDRProgrammer V2 and HPSDRBootloader Programmer and > Maintainer > > > On Sun, Aug 31, 2014 at 4:57 PM, Jim Sanford > wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > All: > I am finally assembling the system I purchased in pieces long ago > from TAPR. > > I have successfully updated Metis firmware to the latest. > > I have installed J1 in Metis to put it in bootloader mode. > > I have installed J7 (last JTAG) jumper on Mercury. > > Running HPSDRProgrammer V2 version 2.0.4.0 > > All the LEDs on Mercury that the manual says should be lit are. > > When I click DISCOVER, Mercury is not found, and I get an error > message telling me to "Make sure the correct interface is > attached. There is only one interface -- the ethernet interface on > the computer. > > Any suggestions?? > > Thanks & 73, > Jim > wb4gcs at amsat.org > > > --- > This email is free from viruses and malware because avast! > Antivirus protection is active. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > > -- > KV0S - Dave Larsen > Columbia, MO, USA --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From beford at myfairpoint.net Sun Aug 31 18:41:29 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Sun, 31 Aug 2014 21:41:29 -0400 Subject: [hpsdr] SOLD Munin amp kits for sale Message-ID: Both Munin amps kits have been spoken for, pending funds. Thanks for all the replies. Bruce N1RX -------------- next part -------------- An HTML attachment was scrubbed... URL: From getpri at t-online.de Sun Aug 31 23:24:58 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 01 Sep 2014 08:24:58 +0200 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: <5404113A.1000700@t-online.de> Hello Jae, wow, good to hear that you were successful so fast. I am interested in your experience to port everything into Ubuntu. I updated my system to Ubuntu 14.04 last week, but I am not very happy with my system as it seems to have some problems. I guess I have to start with a new OS from a CD instead of upgrading. As I am running a dual boot (win7/ubuntu) OS, it is always a problem loading one system from scratch, only. So, I am just in front of starting with HPSDR on linux and eager to get informations about all the pitfalls. 73, Georg DL2KP Am 31.08.2014 22:30, schrieb Jae Stutzman: > ***** High Performance Software Defined Radio Discussion List ***** > > > > After about 3 hours worth of work and a few workarounds, I made my > first QSO on 20 meters under Linux! > > I used MonoDevelop as the IDE for the C# KISS solution. I had to make > a couple of changes for the P/Invokes of the fftw3f library and some > of the Networking calls, which are still not implemented within the > Mono CLR. The performance is quite good, I'll compare it to my Windows > box to see the differences. > > Here is a link to a screenshot of how it looks: > http://imgur.com/AsJ4pSE. I'll document my changes and the > dependencies that I installed to make it work soon. > > Thanks everyone for the welcome and thanks to the authors of KISS > Konsole for making the porting easy :) > > > 73, > > Jae - K5JAE > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Internet: in progress ********************************************************************** IMPORTANTE/IMPORTANT CONFIDENCIAL/CONFIDENTIALITY Este mensaje ha sido elaborado ?nicamente para uso de la persona o entidad a la que es remitido, ya que puede contener informaci?n personal, confidencial y de acuerdo a ley no puede ser difundido. Si el lector de este mensaje no es el destinatario se?alado, o la persona responsable para entregar el mensaje a quien est? dirigido, advertimos que cualquier divulgaci?n, retransmisi?n o copia de esta comunicaci?n esta estrictamente prohibida. Si usted ha recibido esta comunicaci?n por error, por favor s?rvase informarlo de inmediato al remitente por correo electr?nico o tel?fono y borrar inmediatamente el mensaje original. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail kann vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ********************************************************************** --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From la2ni at online.no Fri Aug 1 00:26:03 2014 From: la2ni at online.no (Kjell Karlsen) Date: Fri, 01 Aug 2014 09:26:03 +0200 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: Congratulations Warren! 73, Kjell, LA2NI P? Fri, 01 Aug 2014 07:05:14 +0200, skrev Bill Tracey : > ***** High Performance Software Defined Radio Discussion List ***** > > From > http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, > NR0V, of Santa Cruz, California. Pratt was cited for his research > leading to the development of PureSignal, "an adaptive baseband > pre-distortion algorithm used to improve the linearity of amplifiers and > reduce intermodulation distortion products emitted by software-defined > transmitters." > > Congratulations Warren, and thanks for your excellent contributions! > > Bill (kd5tfd) > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > -- Sendt med Operas e-postklient: http://www.opera.com/mail/ From meijer.ha at home.nl Fri Aug 1 00:56:10 2014 From: meijer.ha at home.nl (H.A. Meijer) Date: Fri, 1 Aug 2014 09:56:10 +0200 (CEST) Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: <1644767958.114768.1406879772837.open-xchange@oxbe3.tb.mail.iss.local> An HTML attachment was scrubbed... URL: From w4yn at earthlink.net Fri Aug 1 04:38:50 2014 From: w4yn at earthlink.net (Tim ORourke) Date: Fri, 1 Aug 2014 07:38:50 -0400 (GMT-04:00) Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner Message-ID: <3589696.1406893130994.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> This is way cool, tnx for all the FB effort for a fantastic solution! Tim Tim O\Rourke W4YN at ARRL.Net Low Power Amateur Radio Rocks Member of Flying Pigs,ARCI,GQRP,RSGB,ARRL Life Member R/C Pilot (sort of) NRA Life Member NRA Certified Rifle, Pistol, Black Powder Instructor, Range Officer -----Original Message----- >From: Bill Tracey >Sent: Aug 1, 2014 1:05 AM >To: HPSDR list >Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner > >***** High Performance Software Defined Radio Discussion List ***** > > From >http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > > * The 2014 ARRL Technical Innovation Award went to Warren C. >Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his >research leading to the development of PureSignal, "an adaptive >baseband pre-distortion algorithm used to improve the linearity of >amplifiers and reduce intermodulation distortion products emitted by >software-defined transmitters." > >Congratulations Warren, and thanks for your excellent contributions! > >Bill (kd5tfd) > > >_______________________________________________ >HPSDR Discussion List >To post msg: hpsdr at openhpsdr.org >Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >HPSDR web page: http://openhpsdr.org >Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From g3vbv at blueyonder.co.uk Fri Aug 1 05:02:31 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Fri, 01 Aug 2014 13:02:31 +0100 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: <53DB81D7.8000506@blueyonder.co.uk> Brilliant News! Absolutely! 73 ... Sid. On 01/08/14 06:05, Bill Tracey wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > From > http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > > * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, > NR0V, of Santa Cruz, California. Pratt was cited for his research > leading to the development of PureSignal, "an adaptive baseband > pre-distortion algorithm used to improve the linearity of amplifiers > and reduce intermodulation distortion products emitted by > software-defined transmitters." > > Congratulations Warren, and thanks for your excellent contributions! > > Bill (kd5tfd) > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > . > -- 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 From abhiarunoday at gmail.com Fri Aug 1 07:06:25 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Fri, 1 Aug 2014 19:36:25 +0530 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner Message-ID: Congratulations Warren, well deserved, Please let me also add that it is a pleasure and an honor to work with Warren, Kudos!!!! Abhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From nealk3nc at gmail.com Fri Aug 1 07:58:12 2014 From: nealk3nc at gmail.com (Neal Campbell) Date: Fri, 1 Aug 2014 10:58:12 -0400 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: References: Message-ID: He is unbelievably talented as well as an incredibly smart dude! Add generous to that list also. Congrats Warren, I could not imagine a more worthy person. 73 Neal Campbell Abroham Neal LLC On Fri, Aug 1, 2014 at 10:06 AM, Abhi A wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > Congratulations Warren, well deserved, > > Please let me also add that it is a pleasure and an honor to work with > Warren, > > Kudos!!!! > > Abhi > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scotty at tonks.com Fri Aug 1 11:23:07 2014 From: scotty at tonks.com (Scott Cowling) Date: Fri, 01 Aug 2014 11:23:07 -0700 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com > References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: <7.0.1.0.2.20140801112159.04ddfcf0@tonks.com> Congratulations, Warren! Very well deserved! 73, Scotty WA2DFI At 00:05 2014-08-01 -0500, Bill Tracey wrote: >***** High Performance Software Defined Radio Discussion List ***** > > From > http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > > * The 2014 ARRL Technical Innovation Award went to Warren C. > Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his > research leading to the development of PureSignal, "an adaptive > baseband pre-distortion algorithm used to improve the linearity of > amplifiers and reduce intermodulation distortion products emitted > by software-defined transmitters." > >Congratulations Warren, and thanks for your excellent contributions! > >Bill (kd5tfd) From ve7mdl at gmail.com Fri Aug 1 12:03:33 2014 From: ve7mdl at gmail.com (Erik Skovgaard) Date: Fri, 1 Aug 2014 12:03:33 -0700 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: Congratulations Warren and thanks for all your hard work! 73 de ve7mdl, ....Erik. Currently marine mobile as ve0mdl On Jul 31, 2014 10:05 PM, "Bill Tracey" wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > From http://www.arrl.org/news/arrl-board-lauds-unforgettable- > milestone-formalizes-lotw-policy-honors-award-recipients > * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, > NR0V, of Santa Cruz, California. Pratt was cited for his research leading > to the development of PureSignal, "an adaptive baseband pre-distortion > algorithm used to improve the linearity of amplifiers and reduce > intermodulation distortion products emitted by software-defined > transmitters." > > Congratulations Warren, and thanks for your excellent contributions! > > Bill (kd5tfd) > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/ > listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beford at myfairpoint.net Fri Aug 1 12:43:56 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Fri, 1 Aug 2014 15:43:56 -0400 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Message-ID: Well deserved recognition for a remarkable advancement of the radio art. Congratulations. Bruce/N1RX From tfox at knology.net Fri Aug 1 16:40:59 2014 From: tfox at knology.net (Terry Fox) Date: Fri, 1 Aug 2014 19:40:59 -0400 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk><53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: I just got in from a day of antenna work, and saw this. Congratulations Warren!!! Your commitment to moving PureSignal forward, along with other SDR work, is impressive indeed!! Keep it up! 73, Terry, WB4JFI -----Original Message----- From: Bill Tracey Sent: Friday, August 01, 2014 1:05 AM To: HPSDR list Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner ***** High Performance Software Defined Radio Discussion List ***** From http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his research leading to the development of PureSignal, "an adaptive baseband pre-distortion algorithm used to improve the linearity of amplifiers and reduce intermodulation distortion products emitted by software-defined transmitters." Congratulations Warren, and thanks for your excellent contributions! Bill (kd5tfd) _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From aa8k73 at gmail.com Fri Aug 1 21:24:26 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Sat, 02 Aug 2014 00:24:26 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/02 Message-ID: <53DC67FA.8060802@gmail.com> The 2/Aug TeamSpeak mp3 (67 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3509 > or < http://www.hamsdr.com/dnld.aspx > Session text follows <20:56:42> *** You are now talking in channel: "OpenHPSDR" <21:00:14> "Mike - AA8K": Congratulations Warren! <21:01:04> "Terry WB4JFI": Yes, Congratulations Warren!! Good work there! <21:01:51> "Warren - NR0V": Thanks very much. I enjoy the work and feel honored to be recognized. <21:24:05> "Mike - AA8K": Recordings: It's my way of contributing to the projects. :) <21:51:39> "Ken N9VV": Basic Configuration ? Tegra K1 SOC ? 2 Gbyte x16 memory with 64 bit width (can accommodate from 1-4 GByte total) ? 16GB 4.51 eMMC memory (footprint expandable from 16-256GByte memory) ? One empty half mini-PCIE slot with one USB and single lane PEX ? One SD/MMC connector ? One USB 2.0 port, micro AB ? One USB 3.0 port, type A ? HDMI port, type A ? TMP451 temperature monitor ? RS232 Serial port routed to UART4 ? ALC5639 Realtek Audio codec with separate MIC in and Line out jacks ? RTL8111GS Realtek GigE LAN/PHY with PEX interface ? One SATA data port ? SPI 4MByte Boot Flash device ? AMS AS3722 Power Management IC for power and sequencing ? Board ID EEPROM Signal Groups Routing to Expansion Headers ? DP / LVDS ? Touch SPI ? Camera_0 (one CSI differential data pair) & Camera_1 (four CSI differential data pairs) <21:51:46> "Ken N9VV": ? GPIO PU(6:0) general purpose IO ? UART ? HSIC ? GEN(2:1)_I2C, PWR_I2C, CAM_I2C ? Miscellaneous Power Connectors and Expansion Headers ? USB 2.0 OTG ? USB 3.0, flag configuration ? 2mm pitch Expansion headers (5x25 configuration) ? RJ45 ethernet with integrated gigabit magnetics ? HDMI type A port ? DSUB9 male serial port ? MIC-in, Headphone-out 3.5mm jacks ? JTAG 2x10 100 mil pitch THM (Through Hole Mount) ? DC power jack <21:52:37> "Rob - VE3EW": rob creswon rcrewson{AT}cinci.rr.com <21:52:53> "Rob - VE3EW": u can see i done type well <21:56:50> "Ken N9VV": Already announced Tablet last week <21:59:52> "Ken N9VV": July 23rd: < http://blogs.nvidia.com/blog/2014/07/23/why-shield-family/ > <22:01:11> "Ken N9VV": < http://www.androidheadlines.com/2014/07/nvidia-shield-tablet-now-available-299.html > <22:02:24> "Ken N9VV": Nvidia Shield Tablet for sale $299 from Amazon <22:06:51> "Ken N9VV": Lake Superior is 1,335 feet deep and 350 miles long. <22:07:05> "Ken N9VV": < http://en.wikipedia.org/wiki/Great_Lakes > <22:11:30> "Warren - NR0V": 73 ... time to go check with the XYL on the dinner plans From nu8i at cox.net Sat Aug 2 12:47:29 2014 From: nu8i at cox.net (Alfred Green) Date: Sat, 02 Aug 2014 12:47:29 -0700 Subject: [hpsdr] FM squelch Message-ID: <53DD4051.5010902@cox.net> Greetings, I'm currently using mRX PS v3.2.17 with a Hermes and homebrew transverters. I rarely operate FM, but a local station was active for the UHF contest with an FM rig on 1296, so I worked him for the point. However, the signal was pretty weak, although quite visible on the waterfall. I would have liked to have opened the squelch to assist with the copy, but setting SQL to zero didn't do the trick. I had to wait for the signal to get a good ways over the noise before the rx would open. I'm pretty sure this worked differently in an earlier release, but as I rarely do this I could be mistaken. Am I missing a setting, or is this performance to be expected? 73 Alf NU8I Phoenix AZ DM33xo From n9vv at wowway.com Sat Aug 2 13:50:40 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Sat, 02 Aug 2014 15:50:40 -0500 Subject: [hpsdr] FM squelch In-Reply-To: <53DD4051.5010902@cox.net> References: <53DD4051.5010902@cox.net> Message-ID: <53DD4F20.3020007@wowway.com> I am not sure that I can offer you a good explanation about this Alf, but you might want to use a calibrated signal source like the Elecraft XG-1 which emits a 50uv = S9 = -73db signal at 7040, and has another setting of -113db = S1 = ?uv with a switch. You can then know that your receiver is properly calibrated with any sort of input. I believe some of the more modern Elecraft calibrators allow you to select any frequency you wish. Perhaps you could substitute the calibrated signal for the IF signal coming from the transverter, and then adjust the SQUELCH on/off and level slider as needed to verify it's tripping levels in your setup. GL de Ken N9VV On 8/2/2014 2:47 PM, Alfred Green wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Greetings, > > I'm currently using mRX PS v3.2.17 with a Hermes and homebrew transverters. > > I rarely operate FM, but a local station was active for the UHF contest > with an FM rig on 1296, so I worked him for the point. > However, the signal was pretty weak, although quite visible on the > waterfall. I would have liked to have opened the squelch to assist with > the copy, but setting SQL to zero didn't do the trick. I had to wait for > the signal to get a good ways over the noise before the rx would open. > > I'm pretty sure this worked differently in an earlier release, but as I > rarely do this I could be mistaken. > > Am I missing a setting, or is this performance to be expected? > > 73 Alf NU8I > Phoenix AZ DM33xo > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From nu8i at cox.net Sat Aug 2 16:34:44 2014 From: nu8i at cox.net (Alfred Green) Date: Sat, 02 Aug 2014 16:34:44 -0700 Subject: [hpsdr] FM squelch In-Reply-To: References: <53DD4051.5010902@cox.net> Message-ID: <53DD7594.8060509@cox.net> On 8/2/2014 1:50 PM, Ken N9VV (Win-7/64) wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I am not sure that I can offer you a good explanation about this Alf, > but you might want to use a calibrated signal source like the Elecraft > XG-1 which emits a 50uv = S9 = -73db signal at 7040, and has another > setting of -113db = S1 = ?uv with a switch. > > You can then know that your receiver is properly calibrated with any > sort of input. I believe some of the more modern Elecraft calibrators > allow you to select any frequency you wish. > > Perhaps you could substitute the calibrated signal for the IF signal > coming from the transverter, and then adjust the SQUELCH on/off and > level slider as needed to verify it's tripping levels in your setup. > Tnx for the comments, Ken. The IF is well calibrated; in fact I have good sources through 10Gigs so that is not the issue. When you mentioned "adjust the SQUELCH on/off and level slider" I had an 'ah-ha' moment; clicking on the 'SQL: xx' box turns on/off the squelch. I had forgotten that was a control, but it does exactly what I needed. Maybe I should just RTFM. GL & 73, Alf NU8I From warren at wpratt.com Sat Aug 2 19:22:37 2014 From: warren at wpratt.com (Warren C. Pratt) Date: Sat, 02 Aug 2014 19:22:37 -0700 Subject: [hpsdr] FM squelch In-Reply-To: <53DD7594.8060509@cox.net> References: <53DD4051.5010902@cox.net> <53DD7594.8060509@cox.net> Message-ID: <53DD9CED.4050900@wpratt.com> Hi Alf, I got out the FM signal generator and did a quick check. All here seems to be working as expected. Setting differences could be the issue. The thing to check first is the sample rate. Because of the bandwidths involved in FM demodulation and modulation, I would not recommend using less than a 192K sample rate for FM. DSP Buffer Size might also be relevant. At 192K, I'd use 4096. In any case, if you are still having difficulty, you've found the workaround for the moment -- the squelch OFF button. Let me know if sample rate / DSP buffer size helps. 73, Warren NR0V On 8/2/2014 4:34 PM, Alfred Green wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > On 8/2/2014 1:50 PM, Ken N9VV (Win-7/64) wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> I am not sure that I can offer you a good explanation about this Alf, >> but you might want to use a calibrated signal source like the >> Elecraft XG-1 which emits a 50uv = S9 = -73db signal at 7040, and has >> another setting of -113db = S1 = ?uv with a switch. >> >> You can then know that your receiver is properly calibrated with any >> sort of input. I believe some of the more modern Elecraft calibrators >> allow you to select any frequency you wish. >> >> Perhaps you could substitute the calibrated signal for the IF signal >> coming from the transverter, and then adjust the SQUELCH on/off and >> level slider as needed to verify it's tripping levels in your setup. >> > > Tnx for the comments, Ken. > The IF is well calibrated; in fact I have good sources through 10Gigs > so that is not the issue. > When you mentioned "adjust the SQUELCH on/off and level slider" I had > an 'ah-ha' moment; clicking on the 'SQL: xx' box turns on/off the > squelch. I had forgotten that was a control, but it does exactly what > I needed. > > Maybe I should just RTFM. > > GL & 73, Alf NU8I > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From nu8i at cox.net Sun Aug 3 08:02:40 2014 From: nu8i at cox.net (Alfred Green) Date: Sun, 03 Aug 2014 08:02:40 -0700 Subject: [hpsdr] FM squelch In-Reply-To: References: <53DD4051.5010902@cox.net> <53DD7594.8060509@cox.net> Message-ID: <53DE4F10.3090503@cox.net> On 8/2/2014 7:22 PM, Warren C. Pratt wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Alf, > > I got out the FM signal generator and did a quick check. All here > seems to be working as expected. Setting differences could be the > issue. The thing to check first is the sample rate. Because of the > bandwidths involved in FM demodulation and modulation, I would not > recommend using less than a 192K sample rate for FM. DSP Buffer Size > might also be relevant. At 192K, I'd use 4096. > > In any case, if you are still having difficulty, you've found the > workaround for the moment -- the squelch OFF button. > > Let me know if sample rate / DSP buffer size helps. > Hello Warren, I appreciate the comments. I'm running at 48k sample rate with 2048 rx buffer size. If I change to 192k sr the squelch slider seems to operate more like I was expecting, ie. with no or little signal, setting squelch to 0 opens the Rx. That may be how I had it set before, so my old memory may not be failing. However, it really isn't an issue anymore, as I have found the on/off button. I have now had a whopping 2 contacts on FM in the last year or so; usually I am on CW/SSB/JT on UHF and up. It was just that a local had an FM HT with him that would work on 1296, so it was worth a shot for a point. If anyone is planning on using FM more seriously then the note about sample rate would be an important consideration. Tnx for everything. 73 Alf NU8I Phoenix AZ DM33xo From i7swx at yahoo.com Sun Aug 3 08:39:01 2014 From: i7swx at yahoo.com (Giancarlo Moda) Date: Sun, 3 Aug 2014 16:39:01 +0100 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner Message-ID: <1407080341.82109.YahooMailNeo@web172003.mail.ir2.yahoo.com> THE VERY BEST CONGRATULATIONS WARREN, this is the minimum we can say for the Aword you received and more for your "brain" contribution to the Ham and professional fields 73 Gian I7SWX Message: 3 Date: Fri, 01 Aug 2014 00:05:14 -0500 From: Bill Tracey To: HPSDR list Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical ??? Innovation Award winner Message-ID: ??? <201408010505.s71556Dv008606 at mail24c25-2209.carrierzone.com> Content-Type: text/plain; charset="us-ascii"; format=flowed From? http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients? ? ? * The 2014 ARRL Technical Innovation Award went to Warren C.? Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his? research leading to the development of PureSignal, "an adaptive? baseband pre-distortion algorithm used to improve the linearity of? amplifiers and reduce intermodulation distortion products emitted by? software-defined transmitters." Congratulations Warren, and thanks for your excellent contributions! Bill (kd5tfd) -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From getpri at t-online.de Mon Aug 4 05:18:57 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 04 Aug 2014 14:18:57 +0200 Subject: [hpsdr] PowerSDR and OZY In-Reply-To: <53DD9CED.4050900@wpratt.com> References: <53DD4051.5010902@cox.net> <53DD7594.8060509@cox.net> <53DD9CED.4050900@wpratt.com> Message-ID: <53DF7A31.4050102@t-online.de> Hello, what is the latest version of PowerSDR working with OZY? What are the appropriate firmware versions for Mercury and Penylane? 73, Georg, DL2KP --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com From vk5lb at yahoo.com.au Mon Aug 4 07:14:27 2014 From: vk5lb at yahoo.com.au (Dean) Date: Mon, 4 Aug 2014 23:44:27 +0930 Subject: [hpsdr] PwrSDR with Ozy Message-ID: Like Georg, there are many who are happy with Ozy, Mercury and Penelope running an old XP version of PwrSDR. I also would like to hear what people are running as far as XP versions of PwrSDR are concerned. I use 1.19.3.4 by W5WC and it is fine. Penelope 1.2 and Mercury 2.9 with single Rx. However is there a better choice? Cheers Dean. From getpri at t-online.de Mon Aug 4 07:44:14 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 04 Aug 2014 16:44:14 +0200 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: References: Message-ID: <53DF9C3E.8010709@t-online.de> Hi Dean, on my OZY-system, I am running OpenHPSDRmRX-FFT v3.2.1(12/23/13). The question is, if there are newer versions compatibel with OZY. I remember that somebody mentioned on this forum, that this should be the last version for OZY, but I am not shure. 73, Georg, dl2kp Am 04.08.2014 16:14, schrieb Dean: > ***** High Performance Software Defined Radio Discussion List ***** > > Like Georg, there are many who are happy with Ozy, Mercury and Penelope running an old XP version of PwrSDR. I also would like to hear what people are running as far as XP versions of PwrSDR are concerned. I use 1.19.3.4 by W5WC and it is fine. Penelope 1.2 and Mercury 2.9 with single Rx. However is there a better choice? > > Cheers Dean. > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- Internet: in progress ********************************************************************** IMPORTANTE/IMPORTANT CONFIDENCIAL/CONFIDENTIALITY Este mensaje ha sido elaborado ?nicamente para uso de la persona o entidad a la que es remitido, ya que puede contener informaci?n personal, confidencial y de acuerdo a ley no puede ser difundido. Si el lector de este mensaje no es el destinatario se?alado, o la persona responsable para entregar el mensaje a quien est? dirigido, advertimos que cualquier divulgaci?n, retransmisi?n o copia de esta comunicaci?n esta estrictamente prohibida. Si usted ha recibido esta comunicaci?n por error, por favor s?rvase informarlo de inmediato al remitente por correo electr?nico o tel?fono y borrar inmediatamente el mensaje original. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail kann vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ********************************************************************** --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com From ct1izu at sapo.pt Mon Aug 4 08:54:18 2014 From: ct1izu at sapo.pt (ct1izu) Date: Mon, 4 Aug 2014 16:54:18 +0100 Subject: [hpsdr] PwrSDR with Ozy References: Message-ID: <3C85201767F1422FBF481CBE40D6E427@dd52f851956584> Hi Dean My system at CT1IZU is OZY 2.1 Merc 3.1 Penny 1.6 used on a mini ITX D525 (1.8ghz) from Asus running an Nlited XP with SP2. works well but there are some issues on shutdown with it notnot saving data correctly. Shel CT1IZU From ct1izu at sapo.pt Mon Aug 4 08:58:42 2014 From: ct1izu at sapo.pt (ct1izu) Date: Mon, 4 Aug 2014 16:58:42 +0100 Subject: [hpsdr] PwrSDR with Ozy References: Message-ID: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> Dean Too much Vino Tinto Missed the important info pwr SDR Ver 3.2.9 2.23.14 Shel CT1IZU From k5so at valornet.com Mon Aug 4 09:38:47 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 4 Aug 2014 10:38:47 -0600 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> References: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> Message-ID: <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> All, Ozy is still being supported. Ozy works with the current versions of firmware and software on the OpenHPSDR download page (http://openhpsdr.org/download.php). In particular, the current official versions of firmware for Ozy based systems are: PowerSDR_mRX_PS_v3.2.17.0 Ozy v2.7 (included in the PowerSDR_mRX_PS_v3.2.17.0 folder and loads automatically when Ozy is selected as hardware and the initozy11.bat file is edited to point to Ozy_Janus.v27.rbf file) Mercury v3.4 Penelope v1.8 PureSignal is not implemented in any of the Atlas-based systems at the present time so that option in PowerSDR is not available when running Ozy (or Metis). Keep in mind that you may not mix ?old? firmware versions with firmware version that are later than 4May2013 (i.e., Ozy_Janus_v2.5 in the case for Ozy) as a major change for all the Atlas-based boards was made to implement a new I2C bus communications scheme between Ozy(or Metis) and the Mercury/Penelope boards. If you use a version of current firmware in any of the Ozy/Mercury/Penelope boards you must use current firmware in all of the boards (recommended). 73, Joe K5SO From getpri at t-online.de Mon Aug 4 10:32:59 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 04 Aug 2014 19:32:59 +0200 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> References: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> Message-ID: <53DFC3CB.1000502@t-online.de> Thank you Joe and all who responded. Best wishes and 73 Georg, DL2KP Am 04.08.2014 18:38, schrieb Joe Martin K5SO: > ***** High Performance Software Defined Radio Discussion List ***** > > > All, > > Ozy is still being supported. Ozy works with the current versions of firmware and software on the OpenHPSDR download page (http://openhpsdr.org/download.php). > > In particular, the current official versions of firmware for Ozy based systems are: > > PowerSDR_mRX_PS_v3.2.17.0 > > Ozy v2.7 (included in the PowerSDR_mRX_PS_v3.2.17.0 folder and loads automatically when Ozy is selected as hardware and the initozy11.bat file is edited to point to Ozy_Janus.v27.rbf file) > > Mercury v3.4 > > Penelope v1.8 > > PureSignal is not implemented in any of the Atlas-based systems at the present time so that option in PowerSDR is not available when running Ozy (or Metis). > > Keep in mind that you may not mix ?old? firmware versions with firmware version that are later than 4May2013 (i.e., Ozy_Janus_v2.5 in the case for Ozy) as a major change for all the Atlas-based boards was made to implement a new I2C bus communications scheme between Ozy(or Metis) and the Mercury/Penelope boards. > > If you use a version of current firmware in any of the Ozy/Mercury/Penelope boards you must use current firmware in all of the boards (recommended). > > 73, Joe K5SO > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- Internet: in progress ********************************************************************** IMPORTANTE/IMPORTANT CONFIDENCIAL/CONFIDENTIALITY Este mensaje ha sido elaborado ?nicamente para uso de la persona o entidad a la que es remitido, ya que puede contener informaci?n personal, confidencial y de acuerdo a ley no puede ser difundido. Si el lector de este mensaje no es el destinatario se?alado, o la persona responsable para entregar el mensaje a quien est? dirigido, advertimos que cualquier divulgaci?n, retransmisi?n o copia de esta comunicaci?n esta estrictamente prohibida. Si usted ha recibido esta comunicaci?n por error, por favor s?rvase informarlo de inmediato al remitente por correo electr?nico o tel?fono y borrar inmediatamente el mensaje original. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail kann vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ********************************************************************** --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com From wb4gcs at wb4gcs.org Mon Aug 4 15:02:02 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Mon, 04 Aug 2014 18:02:02 -0400 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> References: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> Message-ID: <53E002DA.1080004@wb4gcs.org> Joe: I'm a bit confused by the "keep in mind" paragraph. Does this mean there is some hardware version at which the firmware splits? I have an atlas/ozy/janus system that is probably near original hardware from TAPR. Will the latest firmware you mention below run on that system, or is there some version at which that hardware is no longer supported? Thanks & 73, Jim wb4gcs at amsat.org On 8/4/2014 12:38 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > All, > > Ozy is still being supported. Ozy works with the current versions of firmware and software on the OpenHPSDR download page (http://openhpsdr.org/download.php). > > In particular, the current official versions of firmware for Ozy based systems are: > > PowerSDR_mRX_PS_v3.2.17.0 > > Ozy v2.7 (included in the PowerSDR_mRX_PS_v3.2.17.0 folder and loads automatically when Ozy is selected as hardware and the initozy11.bat file is edited to point to Ozy_Janus.v27.rbf file) > > Mercury v3.4 > > Penelope v1.8 > > PureSignal is not implemented in any of the Atlas-based systems at the present time so that option in PowerSDR is not available when running Ozy (or Metis). > > Keep in mind that you may not mix ?old? firmware versions with firmware version that are later than 4May2013 (i.e., Ozy_Janus_v2.5 in the case for Ozy) as a major change for all the Atlas-based boards was made to implement a new I2C bus communications scheme between Ozy(or Metis) and the Mercury/Penelope boards. > > If you use a version of current firmware in any of the Ozy/Mercury/Penelope boards you must use current firmware in all of the boards (recommended). > > 73, Joe K5SO > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From beford at myfairpoint.net Mon Aug 4 17:31:08 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Mon, 4 Aug 2014 20:31:08 -0400 Subject: [hpsdr] PwrSDR with Ozy Message-ID: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> Jim- The have been no changes in the hardware. Joe's reminder is that if you are using firmware later than 4May13 in one board, you must use firmware later than that date in ALL the boards on the system. This is because some signals were redefined at that time. The hardware hasn't changed, but the purpose of some of the various signal pins did (defined by the firmware, not the hardware). So- don't mix old board firmware and newer firmware in an Atlas-based system. I hope this helps. Bruce/N1RX > Joe: > I'm a bit confused by the "keep in mind" paragraph. Does this mean > there is some hardware version at which the firmware splits? From k5so at valornet.com Mon Aug 4 17:39:01 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 4 Aug 2014 18:39:01 -0600 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> References: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> Message-ID: -ditto. Thanks Bruce, I was out today. 73, Joe K5SO On Aug 4, 2014, at 6:31 PM, Bruce Beford wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Jim- > The have been no changes in the hardware. Joe's reminder is that if you are > using firmware later than 4May13 in one board, you must use firmware later > than that date in ALL the boards on the system. This is because some signals > were redefined at that time. The hardware hasn't changed, but the purpose of > some of the various signal pins did (defined by the firmware, not the > hardware). So- don't mix old board firmware and newer firmware in an > Atlas-based system. > I hope this helps. > Bruce/N1RX > >> Joe: >> I'm a bit confused by the "keep in mind" paragraph. Does this mean >> there is some hardware version at which the firmware splits? > > From wb4gcs at wb4gcs.org Mon Aug 4 18:10:53 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Mon, 04 Aug 2014 21:10:53 -0400 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: References: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> Message-ID: <53E02F1D.1070505@wb4gcs.org> Bruce & Joe: Got it, thanks! FYI, I intend to use Janus/Ozy with a 2-slot Atlas I picked up somewhere to interface to a UHFSDR, which is the IF for my microwave stack: 222, 903,1293, 2304, 3446, 5763 and 10368. The last two will be double-conversion to obey the IF >= 0.1 RF rule. 73, Jim wb4gcs at amsat.org On 8/4/2014 8:39 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > -ditto. Thanks Bruce, I was out today. > > 73, Joe K5SO > > On Aug 4, 2014, at 6:31 PM, Bruce Beford wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Jim- >> The have been no changes in the hardware. Joe's reminder is that if you are >> using firmware later than 4May13 in one board, you must use firmware later >> than that date in ALL the boards on the system. This is because some signals >> were redefined at that time. The hardware hasn't changed, but the purpose of >> some of the various signal pins did (defined by the firmware, not the >> hardware). So- don't mix old board firmware and newer firmware in an >> Atlas-based system. >> I hope this helps. >> Bruce/N1RX >> >>> Joe: >>> I'm a bit confused by the "keep in mind" paragraph. Does this mean >>> there is some hardware version at which the firmware splits? >> > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From carcia at sbcglobal.net Tue Aug 5 08:26:00 2014 From: carcia at sbcglobal.net (FRANCIS CARCIA) Date: Tue, 5 Aug 2014 08:26:00 -0700 Subject: [hpsdr] IMD Message-ID: <1407252360.20359.YahooMailNeo@web184705.mail.ne1.yahoo.com> Hi All, ?As a suffering Giants football fan and a long time chaser of the IMD monster. Congradulations Warren. I will be starting metal work on my QRO SS linear soon now that my slabs of copper have returned from the machine shop. Great Job. Frank WA1GFZ -------------- next part -------------- An HTML attachment was scrubbed... URL: From k2ue at rochester.rr.com Thu Aug 7 15:42:19 2014 From: k2ue at rochester.rr.com (Clyde Washburn) Date: Thu, 7 Aug 2014 18:42:19 -0400 Subject: [hpsdr] Remote Control? Message-ID: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> What is the state of the art in remote control of an OpenHPSDR Tranceiver (such as an Anan) via an internet connection with 1 or 2Mb/s uplink and typical latency? I know OpenHPSDR can be operated via Remote Desktop, but what is the optimal setup for Rx audio to the remote site and Tx audio to the Transceiver, i.e. a full, functioning remote setup? ___________________ Clyde Washburn, K2UE k2ue at ieee.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From n9vv at wowway.com Thu Aug 7 16:11:24 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Thu, 07 Aug 2014 18:11:24 -0500 Subject: [hpsdr] Remote Control? In-Reply-To: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> References: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> Message-ID: <53E4079C.1040203@wowway.com> Hi Clyde, I think the optimal (consultant) answer will cost more than your whole station :-) Here is a list of REMOTE CONTROL programs that are popular. Each claims to be the best. Some have full Audio support: ---------------------------------------------- http://www.remotehams.com/ Any Desk SplashTOP Screen Hero Google Remote Teamviewer Mikogo Parallels Access http://www.dxzone.com/catalog/Contesting/Stations/ (50 entries) http://www.dxzone.com/catalog/Manufacturers/Remote_Control/ (5) http://www.dxzone.com/catalog/Operating_Modes/Remote_Operations/ (9) http://www.dxzone.com/dx6349/internet-remote-base-society.html http://www.dxzone.com/dx13063/remote-controlled-hf-operations.html http://www.dxzone.com/dx24426/remoterig.html UltraVNC TightVNC TinyVNC Skype (for audio) ipSound (discontinued in 2006, but still popular) HPSDR (Android application for Internet Remote for OpenHPSDR written by G0ORX/N6LYT) QtRadio (Win/Lin/MAC remote application for OpenHPSDR written by G0ORX/N6LYT) glSDR - Android QtRadio client with full control written by volunteers for OpenHPSDR ---------------------------------------------- George, K5RIG, and I are currently testing each of these programs to see if any one of them might be suitable. Remote Control of a PC seems to be a very popular topic - and one that has *NOT* been resolved into a manageable set of alternatives. The fellows at RemoteHams.COM have a very attractive setup. So do a dozen others, all at varying prices and kinds of rigs. Flex Radio Systems is going to put Remote Operation on the top of their Developers list this year. They took a show of hands at their Dayton-2014 Banquet and *Remote Operation* was at the top of the list of desired features that their 6000 owners desired. So there is a good list of resources and you can begin your award winning book about "Remote Ham Radio Station Operation" -- or has the ARRL already done that? (hihihi). GL de Ken N9VV On 8/7/2014 5:42 PM, Clyde Washburn wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > What is the state of the art in remote control of an OpenHPSDR > Tranceiver (such as an Anan) via an internet connection with 1 or 2Mb/s > uplink and typical latency? I know OpenHPSDR can be operated via Remote > Desktop, but what is the optimal setup for Rx audio to the remote site > and Tx audio to the Transceiver, i.e. a full, functioning remote setup? > > ___________________ > > Clyde Washburn, K2UE > > k2ue at ieee.org > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From aa8k73 at gmail.com Thu Aug 7 17:14:16 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Thu, 07 Aug 2014 20:14:16 -0400 Subject: [hpsdr] Remote Control? In-Reply-To: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> References: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> Message-ID: <53E41658.9060607@gmail.com> I don't believe that you will be able to transmit CW remotely in the future Clyde. From what I have gleaned about the Generation 2 HPSDR hardware, the telegraph key will be connected to the FPGA on the transmitter board itself as an effort to reduce latency. This is useful if you are physically near the transmitter, but if you have Repetitive Strain Injury ("glass arm") or another disability requiring you use a keyboard instead of wiggling a lever, or want to operate remotely, or to use any type of CW transmitting software, I'm guessing that you would need to tinker some sort of RS-232 type of kludge. On 14-08-07 06:42 PM, Clyde Washburn wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > What is the state of the art in remote control of an OpenHPSDR > Tranceiver (such as an Anan) via an internet connection with 1 > or 2Mb/s uplink and typical latency? I know OpenHPSDR can be > operated via Remote Desktop, but what is the optimal setup for > Rx audio to the remote site and Tx audio to the Transceiver, > i.e. a full, functioning remote setup? > > ___________________ > > Clyde Washburn, K2UE > > k2ue at ieee.org > From pa0tbr at mubo.nl Sat Aug 2 13:56:17 2014 From: pa0tbr at mubo.nl (Ton PA0TBR) Date: Sat, 2 Aug 2014 22:56:17 +0200 Subject: [hpsdr] Compile environement for PowerSDR_HPSDR_mRX_PS Message-ID: Hello, Is Visual Studio 2010 Express the correct environment to compile PowerSDR_HPSDR_mRX_PS? Are there any development notes available? 73, Ton PA0TBR -------------- next part -------------- An HTML attachment was scrubbed... URL: From vk5lb at yahoo.com.au Fri Aug 8 07:46:10 2014 From: vk5lb at yahoo.com.au (Dean PROBERT) Date: Fri, 8 Aug 2014 07:46:10 -0700 Subject: [hpsdr] Downloading Mercury 3.4 In-Reply-To: Message-ID: <1407509170.73138.YahooMailBasic@web120405.mail.ne1.yahoo.com> Thanks for the info I successfully downloaded all files listed below except Mercury V3,4, All I saw was the raw code. How can I download the file? ???????????? From jeffrie at talktalk.net Fri Aug 8 08:42:28 2014 From: jeffrie at talktalk.net (Jeff Cook) Date: Fri, 8 Aug 2014 16:42:28 +0100 Subject: [hpsdr] Downloading Mercury 3.4 Message-ID: <000001cfb31f$5d4736e0$17d5a4a0$@talktalk.net> Dean, try http://svn.tapr.org/repos_sdr_hpsdr/trunk/Mercury/Source/Mercury_V3.4/ Jeff, G0AFQ. -------------- next part -------------- An HTML attachment was scrubbed... URL: From k2xx at swva.net Fri Aug 8 14:19:01 2014 From: k2xx at swva.net (Joe Giacobello, K2XX) Date: Fri, 08 Aug 2014 17:19:01 -0400 Subject: [hpsdr] Hermes Breakout Brd 2-pin Header Message-ID: <53E53EC5.60209@swva.net> In procrastinating my assembly of the breakout board, I seemed to have lost one of the 2-pin PCB headers. If someone has a spare and can put it in an envelope and mail to my CBA, I'd be happy to reimburse by PayPal or whatever payment method works. Thanks for your help. 73, Joe K2XX From aa8k73 at gmail.com Fri Aug 8 20:33:06 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 08 Aug 2014 23:33:06 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/09 Message-ID: <53E59672.6040100@gmail.com> The 9/Aug TeamSpeak mp3 (51 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3510 > or < http://www.hamsdr.com/dnld.aspx > Session text follows <20:41:19> *** You are now talking in channel: "OpenHPSDR" <21:03:28> "Ken N9VV": Nvida Jetson TK1 - Xwindows remote to Windows PC: https://www.youtube.com/watch?v=Z64z_R7MSMU <21:11:12> "Bill - KD5TFD": Yes yes .. TAPR DCC beginning of Sept <21:15:52> "Rick - VE3MM": Rob, Here is the digikey part number for the Hermes extension cable 'A3AKB-1018G-ND'. <21:16:42> "Bill - KD5TFD": AQRP charts on STM32F4 based sdr: https://dl.dropboxusercontent.com/u/14377548/2014%20SummerFest_1.pdf <21:17:04> "Bill - KD5TFD": and: http://stm32-sdr.com/ <21:17:28> "Rob - VE3EW": thanks Rick <21:20:41> "Phil-VK6PH": http://www.ab4oj.com/sdr/apache/anan100d200d_notes.pdf <21:20:45> "Bill - KD5TFD": works ok here <21:21:11> "Ken N9VV": http://www.ab4oj.com/sdr/apache/anan100d200d_notes.pdf FB Here <21:21:38> "Bill - KD5TFD": IE? <21:21:39> "Bill - KD5TFD": IE? <21:21:46> "Bill - KD5TFD": Use a real real browser1 <21:21:49> "Bill - KD5TFD": Use a real real browser! <21:26:37> "Ken N9VV": God! that Keying Envelope looks *GREAT* <21:42:05> "Rick - VE3MM": 73 guys see you next week <21:45:38> "Bill - KD5TFD": sarcasm <22:07:16> "Bill - KD5TFD": so do macs <22:07:20> "Bill - KD5TFD": and linuii's <22:08:02> "Bill - KD5TFD": never do the fix my pc stuff imho From vk6vz at arach.net.au Sat Aug 9 07:42:26 2014 From: vk6vz at arach.net.au (Steve Ireland) Date: Sat, 9 Aug 2014 22:42:26 +0800 Subject: [hpsdr] For Sale: Munin PA kit and Tmate 2 USB SDR Control Console Message-ID: <4F58396271064EC8B49A5020427EA8F8@StevesHPpcPC> G?day I have for sale an HPSDR Munin Power Amplifier kit compiled by Don K3DLW and a WoodBox Radio Tmate2 USB SDR Control Console in ?as new? condition. The Tmate2 has been used with OpenHPSDR W5WC v2.2.12 and all its functionality was available with this software except for the wattmeter. The Munin Power Amplifier Kit is for sale at $200 Australian and has not been opened. The WoodBox Radio Tmate2 is 15 months old, cost 260 Euros (approx. $375 Australian) and is for sale at $300 Australian. Postage on both items will be extra. If you are interested in either item, please email me. Thank you. Vy 73 Steve, VK6VZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ad0es at ad0es.net Sat Aug 9 08:26:15 2014 From: ad0es at ad0es.net (AD0ES) Date: Sat, 9 Aug 2014 09:26:15 -0600 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: Message-ID: Hi, I wrote earlier about my issues getting a metis/mercury working. Finally had success last nite! For the record, I found the following: The mercury as shipped from TAPR had unknown/non-working firmware installed: > Mercury Software version: 255 (0xFF) I upgraded metis to 2.9 and mercury to 3.4. I tried 4 different software packages, only one works. Each was built from sources obtained from their motherload several weeks ago: ghpsdr: seg-faults on startup. ghpsdr3: works. ghpsdr3-Qt: dspserver seg-faults on startup. ghpsdr3-alex: runs, but is "deaf" <<< this was the version I did most of my early testing with Using ubuntu 64-bit 14.04.1 I am going after the seg-faults next, any wisdom on this issue gladly accepted... Steve AD0ES On Jul 23, 2014, at 9:47 AM, AD0ES wrote: > Using ghpsdr3-alex. > > ------------------- > Start hpsdr-server: > /usr/local/bin/hpsdr-server --metis --interface eth0 --10mhzsource mercury --122.88mhzsource mercury > > ... > > Mercury Software version: 255 (0xFF) From k2xx at swva.net Sat Aug 9 08:46:07 2014 From: k2xx at swva.net (Joe Giacobello, K2XX) Date: Sat, 09 Aug 2014 11:46:07 -0400 Subject: [hpsdr] Hermes Breakout Brd 2-pin Header (Got it!) Message-ID: <53E6423F.90801@swva.net> K6GGO kindly offered to send me the part. Many thanks, Joe K2XX In procrastinating my assembly of the breakout board, I seemed to have lost one of the 2-pin PCB headers. If someone has a spare and can put it in an envelope and mail to my CBA, I'd be happy to reimburse by PayPal or whatever payment method works. Thanks for your help. 73, Joe K2XX From cmwalker at mweb.co.za Sat Aug 9 21:40:10 2014 From: cmwalker at mweb.co.za (Conrad Walker) Date: Sun, 10 Aug 2014 06:40:10 +0200 Subject: [hpsdr] PowerSDR & OZY/Mercury/Penelope updating Message-ID: <002c01cfb455$2c0e2ca0$842a85e0$@co.za> Hello all I decided to update my Ozy/Mercury/Penelope HPSDR on WinXP to v2.7/v3.4/v1.8 with PowerSDR v3.2.17.0. Try as I might, I could not flash Mercury with v3.4 firmware via Ozy with USB-Blaster & either Quartus 9.1, 10.1, 12.1 or 13.0. Quartus 9.10 &10.1 gave an error "file Mercury-v3.4.jic corrupted" - unknown argument "Mercury-3.4.cdf", refer to help for legal arguments. Quartus 12.1 and 13.0 gave a "device not ready" error. I was able to flash Mercury v3.3 with Quartus 9.1 & 10.1, and all Quartus versions successfully flashed Penelope v1.8. I was able to run PowerSDR v3.2.17.0 with Mercury v3.3 and Penny v1.7 but found that the CW setup option to use Ozy/Hermes for CW keying no longer exists, and so can no longer run CW with my present setup, My earlier PowerSDR installation worked fine. Any ideas on sorting this out would be most appreciated. 73, Conrad Walker ZS6BQQ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.montefusco at gmail.com Sun Aug 10 11:03:11 2014 From: andrea.montefusco at gmail.com (andrea montefusco) Date: Sun, 10 Aug 2014 20:03:11 +0200 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> Message-ID: On Sun, Aug 10, 2014 at 3:57 PM, AD0ES wrote: > I am aware of cuSDR, but a quick google didn't find the motherload for linux src, any links? As per http://openhpsdr.org/download.php the source are foud in http://svn.tapr.org/repos_sdr_hpsdr/trunk/DL3HVH/cuSDR64/ it requires Qt 4.8. From lu9cbl at gmail.com Sun Aug 10 11:16:00 2014 From: lu9cbl at gmail.com (lu9cbl at gmail.com) Date: Sun, 10 Aug 2014 15:16:00 -0300 Subject: [hpsdr] Starting with HPSDR from Argentina Message-ID: <53E7B6E0.30606@gmail.com> Hi to all... if i want to start with HPSDR, only with the "Atlas Bus", "Mercury Receiver" and the filters "Alex RX" can it works?? or i?m need another "module" for example "Comunication (Ozy, Magister, Metis)"??? Here in Argentina it?s very difficult to buy international ?tems, because we have several filters for import materials... so maybe i can buy the PCBs and make the boards with local components, or buy only the important componentes. I Have a friend that will be going to USA the next month, so he can bring it to me in his briefcase. Thanks in Advance and sorry for my poor english, i hope you can undesrtand me. Mati LU9CBL --- Este mensaje no contiene virus ni malware porque la protecci?n de avast! Antivirus est? activa. http://www.avast.com From wulf at ping.net.au Sun Aug 10 15:16:09 2014 From: wulf at ping.net.au (Berndt Josef Wulf) Date: Mon, 11 Aug 2014 07:46:09 +0930 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> Message-ID: <1407708969.5462.23.camel@Barossa> G'day, A modified version of cuSDR can be downloaded from http://www.ping.net.au/20140126_cuSDR64src.tar.gz It requires QT5 and may not work with the current firmware change, so your mileage may wary. 73, Berndt VK5ABN On Sun, 2014-08-10 at 20:03 +0200, andrea montefusco wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > On Sun, Aug 10, 2014 at 3:57 PM, AD0ES wrote: > > I am aware of cuSDR, but a quick google didn't find the motherload for linux src, any links? > > As per http://openhpsdr.org/download.php the source are foud in > > http://svn.tapr.org/repos_sdr_hpsdr/trunk/DL3HVH/cuSDR64/ > > it requires Qt 4.8. > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From k5so at valornet.com Sun Aug 10 17:52:18 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 10 Aug 2014 18:52:18 -0600 Subject: [hpsdr] Starting with HPSDR from Argentina In-Reply-To: <53E7B6E0.30606@gmail.com> References: <53E7B6E0.30606@gmail.com> Message-ID: <7FC10CDE-148A-426A-AE9C-7935A4EB8C25@valornet.com> Your English is fine, Mati; no problem. Congratulations on thinking of putting together an Atlas-based HPSDR system. In addition to the Atlas bus, Mercury board, and Alex RX filter you will need a board to communicate with your computer; a Metis (ethernet) board or an Ozy (USB) or a Magister (USB); only one of those three computer comm boards, not all three. I recommend Metis, personally, as the ethernet connection is much superior to the USB methods, especially for high data rates that are necessary for wide bandwidths, but Ozy or Magister will work if you decide to use one of them instead. Also, if you use only the Alex RX filter you will have only high pass filtering on your receiver. If you wish to have bandpass filtering you will also need to use the Alex TX filter with the Alex RX filter. The Alex TX filter board provides low pass filtering. Together the Alex RX and Alex TX provide bandpass filtering. Of course, you can run simply a Mercury receiver and a Metis (or Ozy or Magister) on your Atlas bus to have a functional RX radio, without any Alex filters at all, if you wish to try that configuration first before purchasing Alex filter boards. The Alex filters are excellent filter boards and certainly enhance the operations, especially if you are in a location with large out-of-band signals present. I use both TX and RX Alex filters here and find them to be extremely useful to keep from overloading the Mercury receiver when large out-of-band signals are present. Good luck! 73, Joe K5SO On Aug 10, 2014, at 12:16 PM, lu9cbl at gmail.com wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi to all... if i want to start with HPSDR, only with the "Atlas Bus", "Mercury Receiver" and the filters "Alex RX" can it works?? or i?m need another "module" for example "Comunication (Ozy, Magister, Metis)"??? > > Here in Argentina it?s very difficult to buy international ?tems, because we have several filters for import materials... so maybe i can buy the PCBs and make the boards with local components, or buy only the important componentes. I Have a friend that will be going to USA the next month, so he can bring it to me in his briefcase. > > Thanks in Advance and sorry for my poor english, i hope you can undesrtand me. > Mati LU9CBL > > --- > Este mensaje no contiene virus ni malware porque la protecci?n de avast! Antivirus est? activa. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From douglas.adams at me.com Mon Aug 11 04:45:39 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 07:45:39 -0400 Subject: [hpsdr] Radio (Board) Identification Message-ID: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> I would like to propose a small change to the firmware of all of the OpenHPSDR-derived radios. The purpose of this change would be to make the firmware update process more automatic and foolproof. If you look in Metis- How it works_V1.31 you will see that the Discovery packet returns the following: The payload of the UDP/IP reply frame is as follows: <0xEFFE>< Metis MAC Address><49 bytes of 0x00> where Board_ID = 1 byte, 0x00 = Metis, 0x01 = Hermes, 0x02 = Griffin, 0x04 = Angelia, 0x05 = Orion Currently the Board_ID field (one byte) is not very informative. If it says I have a Hermes (0x01) is it a TAPR Hermes, an ANAN-100, an ANAN-100B, an ANAN-100D, etc. Couldn't we use the 8 bits (256 possibilities) in this field to be more specific about the radio? Perhaps to be backward compatible we could reserve the least significant 4 bits for Board ID and use the most significant four bits for a Sub ID indicating which variant of the Board ID is present. If we coupled this change with a "gentlemen's agreement" to name all firmware files in some recognizable way, something like RadioName_vN.M.rbf ( e.g. ANAN100B_v2.4.rbf ) then it would be possible to write a programmer application that would only show you firmware choices appropriate for the radio you are trying to program. The current arrangement seems uninformative and error prone. 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From ad0es at ad0es.net Mon Aug 11 06:33:44 2014 From: ad0es at ad0es.net (AD0ES) Date: Mon, 11 Aug 2014 07:33:44 -0600 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: Message-ID: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> Hi, Using --hermes instead of --metis does indeed cure the deafness, thanx! So for the record, at this point all 4 programs are working: ghpsdr ghpsdr3 ghpsdr3-Qt ghpsdr3-alex Note that I had to make minor changes to get several of them to compile under Ubuntu 14.04.1 (trusty). Mostly issues of header file locations being moved since the last distro. Steve AD0ES On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES wrote: > >> ghpsdr3-alex: runs, but is "deaf" <<< this was the version I did most of my early testing with > > Steve, > please start the hpsdr-server with --hermes instead of --metis and > report if this cure the issue. From kb3omm at gmail.com Mon Aug 11 07:02:59 2014 From: kb3omm at gmail.com (kb3omm) Date: Mon, 11 Aug 2014 10:02:59 -0400 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> Message-ID: Steve, This is great news. Could you email out the changes you made to get each of the programs to build and run, to aid those like myself who cant program but can follow instructions. I have tried previously to get John's three programs to build on newer versions of Qt and Linux without success. Though, ghpsdr3-alex and cuSDR run fine and use them every day. Hermes, Mint 16, Qt4 and 5 73, Kevin On Mon, Aug 11, 2014 at 9:33 AM, AD0ES wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi, > > Using --hermes instead of --metis does indeed cure the deafness, thanx! > > So for the record, at this point all 4 programs are working: > ghpsdr > ghpsdr3 > ghpsdr3-Qt > ghpsdr3-alex > > Note that I had to make minor changes to get several of them to compile > under Ubuntu 14.04.1 (trusty). Mostly issues > of header file locations being moved since the last distro. > > Steve AD0ES > > On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: > > > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES wrote: > > > >> ghpsdr3-alex: runs, but is "deaf" <<< this was the version I > did most of my early testing with > > > > Steve, > > please start the hpsdr-server with --hermes instead of --metis and > > report if this cure the issue. > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 07:12:51 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 08:12:51 -0600 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> Message-ID: <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> Hi Doug, Interesting proposal that deserves some thought. I don?t disagree that our present system is not a perfect arrangement. Keep in mind however that the Board ID is not the only ID parameter ID that is passed in the packets, the actual firmware version is also passed in the packets in a different byte, so that in itself gives more information than you imply, I believe. The board ID is currently used, among other uses perhaps, by the HPSDR Programmer to determine how long to make the time out limit for the EEPROM erase process; some FPGAs are small (e.g., Metis, Mercury, Penny(Lane), Hermes) and erase quickly compared to the larger (Angelia and Orion) FPGAs that take a while to erase. Dave KV0S didn?t think (and I agree) that it was necessary, nor beneficial, to use a long time out delay for erasing FPGAs that didn?t need one. The current ID method works fine for that purpose and needs no additional expansion. While I certainly appreciate that we might want to specify which specific board type is in use (which we do already in a general sense with the current coarse board ID value) the firmware is used in many cases in a variety of hardware configurations of the same board type so it would not be possible for the firmware developer to write the more detailed ID number into the firmware without knowing ahead of time which of the several configurations for the board type is going to be used with the firmware. In the case of Angelia, as one example, the firmware can be used in any radio that uses the Angelia board such as the ANAN-100D or a barefoot Angelia, or an Angelia with an external PA, or with an Angelia with Alex filters, etc. In your suggestion it would seem that all of those different configurations should ideally have a different board ID value written into the firmware. The firmware design would be identical for those units but your suggested approach would seek to use a different board ?ID? for each of them depending upon how the user wanted to use the Angelia board, which the firmware writer would not know. Having a different board ID for each possible board configuration, and thus a different firmware version for each possible configuration, would lead to many versions of Angelia (etc) firmware for a given firmware design needing to be posted for each release and that in itself would undoubtedly prove to be confusing to the users, in my opinion. I haven?t thought through your suggestion completely but these points came immediately to my mind upon reading your message. Maybe others have comments and suggestions that are constructive for this discussion. Thanks for your thoughts on how we might improve things! Perhaps you have already thought through how to address issues such as these. I?m all for whatever makes the mose sense! 73, Joe K5SO On Aug 11, 2014, at 5:45 AM, Doug Adams wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I would like to propose a small change to the firmware of all of the OpenHPSDR-derived radios. The purpose of this change would be to make the firmware update process more automatic and foolproof. > > If you look in Metis- How it works_V1.31 you will see that the Discovery packet returns the following: > The payload of the UDP/IP reply frame is as follows: > <0xEFFE>< Metis MAC Address><49 bytes of 0x00> > > where > > Board_ID = 1 byte, 0x00 = Metis, 0x01 = Hermes, 0x02 = Griffin, 0x04 = Angelia, 0x05 = Orion > > Currently the Board_ID field (one byte) is not very informative. If it says I have a Hermes (0x01) is it a TAPR Hermes, an ANAN-100, an ANAN-100B, an ANAN-100D, etc. Couldn't we use the 8 bits (256 possibilities) in this field to be more specific about the radio? > > Perhaps to be backward compatible we could reserve the least significant 4 bits for Board ID and use the most significant four bits for a Sub ID indicating which variant of the Board ID is present. > > If we coupled this change with a "gentlemen's agreement" to name all firmware files in some recognizable way, something like RadioName_vN.M.rbf ( e.g. ANAN100B_v2.4.rbf ) then it would be possible to write a programmer application that would only show you firmware choices appropriate for the radio you are trying to program. > > The current arrangement seems uninformative and error prone. > > 73?s > Doug - K3TZR > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wully at bluewin.ch Mon Aug 11 09:03:01 2014 From: wully at bluewin.ch (wully) Date: Mon, 11 Aug 2014 18:03:01 +0200 Subject: [hpsdr] CC-Byte0 from fpga to pc Message-ID: <53E8E935.4090808@bluewin.ch> Hi In the Comand-and-Control-Byte 0 from FPGA to PC there are 3 Bits PTT, Dash and Dot. I would like to use at least one of these bits to control an activity. But I don't know, how these bits are fed. From the schematics of METIS and fpga-code I think that Pins 6,7 and 8 on the DB9 connector should be mapped to these (debounced) Bits, but grounding these does not show an effect on the CC-Byte 0. Hardware: Metis (fpga V2.1) Penelope (fpga 1.7) Mercury (fpga 3.3) 1) Which hardware- bits control the Bits 0..2 of CCbyte0 when using the above hardware? 2) Which hardware- bits control if I use Magister instead of Metis (IN0, IN1 and IN2 are also present there). Thank you for your information. 73, hb9epu From g3vbv at blueyonder.co.uk Mon Aug 11 09:07:25 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 11 Aug 2014 17:07:25 +0100 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> Message-ID: <53E8EA3D.9060807@blueyonder.co.uk> I modified GHPSDR3-Qt/FULL/KV0S/KV0S.pro, adding the Qt include PATHS INCLUDEPATH += . \ /usr/include/QtMultimedia /usr/include/QtNetwork /usr/include/QtXml \ ghpsdr3/DRadio \ griffin/griffinID \ Missing file frequencysender.h:- IQt-Radio-Programs/QtHPSDRServer/client -I. -I. -o receivethread.o hpsdr-programmers/Programmer/receivethread.cpp In file included from hpsdr-programmers/Programmer/receivethread.cpp:37:0: ghpsdr3/DRadio/mainwindow.h:5:29: fatal error: frequencysender.h: No such file or directory #include "frequencysender.h" ^ compilation terminated. make: *** [receivethread.o] Error 1 73 ... Sid. On 11/08/14 15:02, kb3omm wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > Steve, This is great news. > > Could you email out the changes you made to get each of the programs > to build and run, to aid those like myself who cant program but can > follow instructions. > > I have tried previously to get John's three programs to build on newer > versions of Qt and Linux without success. > > Though, ghpsdr3-alex and cuSDR run fine and use them every day. > > Hermes, Mint 16, Qt4 and 5 > > 73, Kevin > > > On Mon, Aug 11, 2014 at 9:33 AM, AD0ES > wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi, > > Using --hermes instead of --metis does indeed cure the deafness, > thanx! > > So for the record, at this point all 4 programs are working: > ghpsdr > ghpsdr3 > ghpsdr3-Qt > ghpsdr3-alex > > Note that I had to make minor changes to get several of them to > compile under Ubuntu 14.04.1 (trusty). ? Mostly issues > of header file locations being moved since the last distro. > > Steve ? AD0ES > > On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: > > > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES > wrote: > > > >> ? ? ? ? ghpsdr3-alex: ? runs, but is "deaf" <<< this was > the version I did most of my early testing with > > > > Steve, > > please start the hpsdr-server with --hermes instead of --metis and > > report if this cure the issue. > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 09:38:40 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 10:38:40 -0600 Subject: [hpsdr] PowerSDR & OZY/Mercury/Penelope updating In-Reply-To: <002c01cfb455$2c0e2ca0$842a85e0$@co.za> References: <002c01cfb455$2c0e2ca0$842a85e0$@co.za> Message-ID: <6282414A-39D6-4B4A-B895-F74A508BACD3@valornet.com> Hi Conrad, I haven?t seen any response on the list for your inquiry so I?ll respond. I wonder if you are using the current USBBinaries-Blaster folder? It can be found at http://svn.tapr.org/repos_sdr_hpsdr/trunk/USBBlaster-Binaries/ If not, please get the latest folder and give those files a try. Even if you do already have the latest USBBlaster-Binaries folder the message below seems to indicate that the files may be corrupted somehow. Therefore, in this case too, I?d download a fresh copy of the USBBlaster-Binaries folder and try them to see if that will work for you. I just checked the current USBBlaster-Binaries/Program-Mercury-EPCS16.bat file in the USBBlaster-Binaries folder to verify that it has options for the current Altera Quartus II v13.0 version and Mercury_v3.4; it does, so it should work I would think. 73, Joe K5SO On Aug 9, 2014, at 10:40 PM, Conrad Walker wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hello all > > I decided to update my Ozy/Mercury/Penelope HPSDR on WinXP to v2.7/v3.4/v1.8 with PowerSDR v3.2.17.0. > > Try as I might, I could not flash Mercury with v3.4 firmware via Ozy with USB-Blaster & either Quartus 9.1, 10.1, 12.1 or 13.0. Quartus 9.10 &10.1 gave an error "file Mercury-v3.4.jic corrupted" - unknown argument "Mercury-3.4.cdf", refer to help for legal arguments. Quartus 12.1 and 13.0 gave a "device not ready" error. I was able to flash Mercury v3.3 with Quartus 9.1 & 10.1, and all Quartus versions successfully flashed Penelope v1.8. > > I was able to run PowerSDR v3.2.17.0 with Mercury v3.3 and Penny v1.7 but found that the CW setup option to use Ozy/Hermes for CW keying no longer exists, and so can no longer run CW with my present setup, My earlier PowerSDR installation worked fine. > > Any ideas on sorting this out would be most appreciated. > > 73, > > Conrad Walker ZS6BQQ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wully at bluewin.ch Mon Aug 11 09:44:50 2014 From: wully at bluewin.ch (wully) Date: Mon, 11 Aug 2014 18:44:50 +0200 Subject: [hpsdr] CC-Byte0 from fpga to pc In-Reply-To: <53E8E935.4090808@bluewin.ch> References: <53E8E935.4090808@bluewin.ch> Message-ID: <53E8F302.2070501@bluewin.ch> Hi I have checked the software and found an error in my code: the ccbyte0 brings the IN0,IN1,IN2-States from all boards, that support these. 73, hb9epu On 11.08.2014 18:03, wully wrote: > Hi > > In the Comand-and-Control-Byte 0 from FPGA to PC there are 3 Bits PTT, > Dash and Dot. > > I would like to use at least one of these bits to control an activity. > But I don't know, how these bits are fed. > From the schematics of METIS and fpga-code I think that Pins 6,7 and 8 > on the DB9 connector should be mapped to these (debounced) Bits, > but grounding these does not show an effect on the CC-Byte 0. > > Hardware: > Metis (fpga V2.1) > Penelope (fpga 1.7) > Mercury (fpga 3.3) > > 1) Which hardware- bits control the Bits 0..2 of CCbyte0 when using > the above hardware? > 2) Which hardware- bits control if I use Magister instead of Metis > (IN0, IN1 and IN2 are also present there). > > Thank you for your information. > > 73, hb9epu > > > > From douglas.adams at me.com Mon Aug 11 10:00:50 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 13:00:50 -0400 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> Message-ID: Joe, Thank you for your comments. Does the firmware file contain the byte representing the Device ID or is it somehow derived by the firmware from the hardware of the board? I would like to be able to prevent (or maybe just warn) a user from selecting an inappropriate firmware file for their Radio. With the current Board ID I can identify the "sub-type" of the Radio (i.e. Metis, Hermes, Angelia, etc). If the firmware file contains the Device ID (maybe someone can tell me how to find that byte in the firmware file), I could compare that to the Device ID of the Radio. Matching those would get me part way to my intent. I'm in the process of adding Firmware Programming into my own SDR app (on a Mac). If you can picture it, I have two lists on screen; a list of the Radios my app can see on the networks attached to the Mac and a list of the Firmware files it can find at various places on the Mac. I expect the user to select a Radio from the first list and a Firmware file from the second list at which point the Erase & Program button is enabled. The question I've been unable to answer is; how to know that I am about to program my Radio with a Firmware version that is somehow inappropriate? There is another layer to Radio (not Board) identification. As you point out, any one firmware file might be used in multiple Radios. Unfortunately, two Radios with the same Board ID might require different firmware. You also mentioned that the firmware version is reported in the protocol. I agree however I believe some versions are being distinguished by placing a letter after the version (e.g. Hermes v2.9b) and I don't believe the suffix is retained or reported back. As far as naming the firmware files goes, each of us can do that ourselves after downloading them but it would be nice if there was an agreed upon naming scheme being used by the creators of the files. It might avoid some errors. Partly my motivation is simply "getting it right" but partly it's because I also see entries in this list where someone has gotten the wrong firmware installed. On Aug 11, 2014, at 10:12 AM, Joe Martin K5SO wrote: > Hi Doug, > > Interesting proposal that deserves some thought. I don?t disagree that our present system is not a perfect arrangement. > > Keep in mind however that the Board ID is not the only ID parameter ID that is passed in the packets, the actual firmware version is also passed in the packets in a different byte > ....... > > While I certainly appreciate that we might want to specify which specific board type is in use (which we do already in a general sense with the current coarse board ID value) the firmware is used in many cases in a variety of hardware configurations > ....... > > 73, Joe K5SO > 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 10:15:38 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 11:15:38 -0600 Subject: [hpsdr] CC-Byte0 from fpga to pc In-Reply-To: <53E8F302.2070501@bluewin.ch> References: <53E8E935.4090808@bluewin.ch> <53E8F302.2070501@bluewin.ch> Message-ID: Okay, very good. I just checked the behavior of bit 2 in the C0 command bytes coming from Metis, using current firmware in all boards, and it responds fine to the DB9 input pin grounding for DASH. I don?t know why you?d want to use old firmware/software but maybe you have a reason to do so. I did not take time to load old version of firmware for these tests. Current firmware is: Metis_v2.9 Mercury_v3.4 Penelope_v1.8 Current software for PSDR is: PowerSDR_mRX_PS_v3.1.17.0 Thanks for updating your situation! 73, Joe K5SO On Aug 11, 2014, at 10:44 AM, wully wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > I have checked the software and found an error in my code: the ccbyte0 brings the IN0,IN1,IN2-States from all boards, that support these. > > 73, hb9epu > > > On 11.08.2014 18:03, wully wrote: >> Hi >> >> In the Comand-and-Control-Byte 0 from FPGA to PC there are 3 Bits PTT, Dash and Dot. >> >> I would like to use at least one of these bits to control an activity. But I don't know, how these bits are fed. >> From the schematics of METIS and fpga-code I think that Pins 6,7 and 8 on the DB9 connector should be mapped to these (debounced) Bits, >> but grounding these does not show an effect on the CC-Byte 0. >> >> Hardware: >> Metis (fpga V2.1) >> Penelope (fpga 1.7) >> Mercury (fpga 3.3) >> >> 1) Which hardware- bits control the Bits 0..2 of CCbyte0 when using the above hardware? >> 2) Which hardware- bits control if I use Magister instead of Metis (IN0, IN1 and IN2 are also present there). >> >> Thank you for your information. >> >> 73, hb9epu >> From kb3omm at gmail.com Mon Aug 11 10:41:31 2014 From: kb3omm at gmail.com (kb3omm) Date: Mon, 11 Aug 2014 13:41:31 -0400 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <53E8EA3D.9060807@blueyonder.co.uk> References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> <53E8EA3D.9060807@blueyonder.co.uk> Message-ID: Steve, Sid, Thanks for your notes. I will try these and report back 73, Kevin On Mon, Aug 11, 2014 at 12:07 PM, Sid Boyce wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > I modified GHPSDR3-Qt/FULL/KV0S/KV0S.pro, adding the Qt include PATHS > INCLUDEPATH += . \ > /usr/include/QtMultimedia /usr/include/QtNetwork > /usr/include/QtXml \ > ghpsdr3/DRadio \ > griffin/griffinID \ > > Missing file frequencysender.h:- > IQt-Radio-Programs/QtHPSDRServer/client -I. -I. -o receivethread.o > hpsdr-programmers/Programmer/receivethread.cpp > In file included from hpsdr-programmers/Programmer/receivethread.cpp:37:0: > ghpsdr3/DRadio/mainwindow.h:5:29: fatal error: frequencysender.h: No such > file or directory > #include "frequencysender.h" > ^ > compilation terminated. > make: *** [receivethread.o] Error 1 > 73 ... Sid. > > On 11/08/14 15:02, kb3omm wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > > > > Steve, This is great news. > > Could you email out the changes you made to get each of the programs to > build and run, to aid those like myself who cant program but can follow > instructions. > > I have tried previously to get John's three programs to build on newer > versions of Qt and Linux without success. > > Though, ghpsdr3-alex and cuSDR run fine and use them every day. > > Hermes, Mint 16, Qt4 and 5 > > 73, Kevin > > > On Mon, Aug 11, 2014 at 9:33 AM, AD0ES wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi, >> >> Using --hermes instead of --metis does indeed cure the deafness, thanx! >> >> So for the record, at this point all 4 programs are working: >> ghpsdr >> ghpsdr3 >> ghpsdr3-Qt >> ghpsdr3-alex >> >> Note that I had to make minor changes to get several of them to compile >> under Ubuntu 14.04.1 (trusty). ? Mostly issues >> of header file locations being moved since the last distro. >> >> Steve ? AD0ES >> >> On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: >> >> > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES wrote: >> > >> >> ? ? ? ? ghpsdr3-alex: ? runs, but is "deaf" <<< this was the >> version I did most of my early testing with >> > >> > Steve, >> > please start the hpsdr-server with --hermes instead of --metis and >> > report if this cure the issue. >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > -- > 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 > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 11:15:47 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 12:15:47 -0600 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> Message-ID: Doug, RR, understood; but I don?t entirely agree with your assessment of the present situation. Let me respond to each of the issues to which I refer: 1) Answering your question: Yes, the firmware Verilog design contains the DEVICE ID number in the Verilog code itself; it?s coded into the ethernet packets directly. For example, the hardware ID value for Angelia is hardcoded in the Angelia Verilog design into line1059 of the TX_MAC module in the Verilog design. It?s done similarly, if not identically, in the Verilog firmware designs for all the other HPSDR and ANAN-series boards. 2) I see what it is that you are trying to accomplish and it?s an admirable goal I think. It seems to me (with one exception which I will mention next) that the current hardware ID scheme works just fine for identifying the hardware to match with firmware. I am not aware of any firmware named for a hardware board that does not work in that board, regardless of the configuration of the board (the exception I mentioned notwithstanding). Namely, the hardware ID specifies whether the board is a Metis, Hermes, Griffin, Angelia, or Orion. The user should be aware, for example, which board his radio uses and therefore be able to match the board with the necessary firmware since the firmware filename includes the board name with which it is intended to be used. 3) The exception I mention above has to do with the minor difference in Apache Labs versions of firmware that are labeled ?b? suffix, in which the switch point for 10m filters is different from radios using Alex filters. The operational effect of not using a ?b? version in an ANAN radio that has the PA filters is perhaps a bit lower maximum output power on 10m; that?s it. Otherwise the firmware will work just fine. 4) I agree with you that labeling firmware versions with a ?b? suffix is not a good idea at all because the firmware version reporting protocol within firmware does not allow for letters in the firmware version numbers. In my opinion, an entirely new firmware version number (using numbers exclusively, no sub-letters) should be used, even for that small distinction of the 10m filter switch point. I always avoid using letter suffix nomenclature in released firmware versions, because there is no way to distinguish those ?modified? versions from the original versions by looking at the version numbers being reported by the firmware. I much prefer to use an entirely different firmware version number which is acceptable in the current firmware version number protocol (no letters) and easily distinguishable from anything else by simply looking at the firmware version number that is reported by the firmware. With regard to loading the wrong firmware, if someone loads Metis code into Angelia, as one example, there really is no excuse for doing it as the Metis firmware has the ?Metis? name in the firmware filename. It?s always a recoverable event in any case, even if it happens. Granted you must use a blaster cable to recover but that?s the penalty you SHOULD have to pay for not reading the name, in my view. Next time you will read it. Further, quite simply, if you own an ANAN radio and don?t even know what major board type the radio has in it (Hermes, Angelia, or Orion) you likely are not well suited to be a user of that radio, as you?re going to have tremendous difficulties operating the thing and updating its firmware later on; my personal opion, of course. I understand your desire to make your code bulletproof against ignorance, and I applaud the attempt, but I think we can go overboard in that area. There are some people who are simply not well suited to using SDR, as I have come to appreciate. I used to think otherwise but sadly now I don?t. These are complex, high-performance radios and they need marginally compentent users at least in order to be able to realize the advantages that they can offer. Again, my opion. You?re all welcome to have a different opinion, if you wish. 73, Joe K5SO From douglas.adams at me.com Mon Aug 11 11:31:54 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 14:31:54 -0400 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> Message-ID: <5C402B1B-058D-4861-A53C-B46863D74269@me.com> Joe (et all), Well stated, let me summarize my take away. 1. If I match the name in the firmware file name (e.g. "Hermes", "Metis", "Angelia") with the Board ID from my Radio (translated to the appropriate string) I will never load a non-operative firmware (it may have minor issues such as the filter control but it will work). 2. We should suggest to those who create firmware files that they only use numbered versions (i.e. no suffixes). I can live with #1, I'll implement it in my code as a Warning (to keep me from doing something dumb, I don't own a Blaster, yet). I'm not sure how we get people to comply with #2. On Aug 11, 2014, at 2:15 PM, Joe Martin K5SO wrote: > Doug, > > RR, understood; but I don?t entirely agree with your assessment of the present situation. Let me respond to each of the issues to which I refer: > > .... > These are complex, high-performance radios and they need marginally compentent users at least in order to be able to realize the advantages that they can offer. Again, my opion. You?re all welcome to have a different opinion, if you wish. > > 73, Joe K5SO > > 73?s Doug - K3TZR From k5so at valornet.com Mon Aug 11 11:46:59 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 12:46:59 -0600 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <5C402B1B-058D-4861-A53C-B46863D74269@me.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> <5C402B1B-058D-4861-A53C-B46863D74269@me.com> Message-ID: <87FDB69E-648D-4E93-953D-89C99190F44A@valornet.com> Doug, Yes. I think #2 will take care of itself given the amount of angst it has caused already, hihi. We learn as we go. 73, Joe K5SO On Aug 11, 2014, at 12:31 PM, Doug Adams wrote: > Joe (et all), > > Well stated, let me summarize my take away. > > 1. If I match the name in the firmware file name (e.g. "Hermes", "Metis", "Angelia") with the Board ID from my Radio (translated to the appropriate string) I will never load a non-operative firmware (it may have minor issues such as the filter control but it will work). > > 2. We should suggest to those who create firmware files that they only use numbered versions (i.e. no suffixes). > > I can live with #1, I'll implement it in my code as a Warning (to keep me from doing something dumb, I don't own a Blaster, yet). I'm not sure how we get people to comply with #2. > > > On Aug 11, 2014, at 2:15 PM, Joe Martin K5SO wrote: > >> Doug, >> >> RR, understood; but I don?t entirely agree with your assessment of the present situation. Let me respond to each of the issues to which I refer: >> >> .... > >> These are complex, high-performance radios and they need marginally compentent users at least in order to be able to realize the advantages that they can offer. Again, my opion. You?re all welcome to have a different opinion, if you wish. >> >> 73, Joe K5SO >> >> > > 73?s > Doug - K3TZR > > > > > > From douglas.adams at me.com Mon Aug 11 11:48:50 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 14:48:50 -0400 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> Message-ID: <1B7A282F-FFC2-4C41-B1BC-B5347FF2DD1A@me.com> Thanks Dave, Although I haven't done any C++ in years I looked through the code and got the idea. I see that you are doing what I've decided to do (see my last post), making sure the firmware file name jives with the Board ID. I also found the definitions for the Max Timeouts for each board which I'll incorporate into my programmer. Hopefully I won't brick my radio in the process of debugging my code. On Aug 11, 2014, at 2:22 PM, Dave Larsen wrote: > Doug -- > > in the HPSDRProgrammer the code you are looking for is in http://svn.tapr.org/repos_sdr_hpsdr/trunk/KV0S/hpsdr-programmers/HPSDRProgrammerV2-nopcap/mainwindow.cpp in the browse function. > > The current HPSDRProgrammer talks to the old firmware to load the flash memory. You are right that the a and b are not kept. Joe and Phil produce most of the firmware for these boards and the naming is up to them. Internally the store the board type and the firmware version is all that is stored and read. > > Part of the issue is some of this changes the bootloader firm, which is install at manufacture not not changed. This is the recover system. we have no causal system for users to replace the bootloader. > > Hope this helps > > Dave KV0S > 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vbv at blueyonder.co.uk Mon Aug 11 13:54:18 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 11 Aug 2014 21:54:18 +0100 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> <53E8EA3D.9060807@blueyonder.co.uk> Message-ID: <53E92D7A.3090004@blueyonder.co.uk> Hi Steve and Kevin, This time instead of the KV0S svn I used "svn co http://svn.tapr.org/repos_sdr_hpsdr/trunk/N6LYT/Qt" which built without changes slipstream:/usr/src/Qt/trunk # ls -l bin total 2484 -rwxr-xr-x 1 root root 1481425 Aug 11 20:33 QtDSPServer -rwxr-xr-x 1 root root??? 396047 Aug 11 20:32 QtHPSDRServer -rwxr-xr-x 1 root root??? 663150 Aug 11 20:34 QtRadio Building on openSUSE which uses lib64 instead of lib. libusb-1.0 is in /usr/include. Makefile changes ========== ghpsdr ---------- INCLUDES=-I. -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/gdk-pixbuf-2.0\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/atk-1.0 -I/usr/include/cairo\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/pango-1.0 -I/usr/include/glib-2.0\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/freetype2 -I/usr/include/libpng12 \ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/libusb-1.0 Exploded and built DttSP.tar.gz in the ghpsdr directory LIBS=-L. -L/usr/src/openHPSDR/ghpsdr/DttSP -lDttSP -lpthread -lusb-1.0\ ??? ??? ??? ??? -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0\ ??? ??? ??? ??? -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lz\ ??? ??? ??? ??? -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lfftw3f slipstream:/usr/src/openHPSDR/ghpsdr # ls -l bin total 1336 -rwxr-xr-x 1 root root 1126746 Aug 11 20:47 ghpsdr -rwxr-xr-x 1 root root??? ??? ??? ??? 256 Aug 11 20:40 ghpsdr.sh -rw-r--r-- 1 root root??? ??? 21032 Aug 11 20:40 icon.png -rwxr-xr-x 1 root root??? ??? ??? 1343 Aug 11 20:40 initozy drwxr-xr-x 2 root root??? ??? ??? 4096 Aug 11 20:40 linux64 -rwxr-xr-x 1 root root??? ??? 14555 Aug 11 20:40 loadFPGA -rwxr-xr-x 1 root root??? ??? 14324 Aug 11 20:40 loadFW drwxr-xr-x 2 root root??? ??? ??? 4096 Aug 11 20:40 mac -rw-r--r-- 1 root root??? ??? 21862 Aug 11 20:40 ozyfw-sdr1k.hex -rw-r--r-- 1 root root??? 121875 Aug 11 20:40 Ozy_Janus.rbf -rwxr-xr-x 1 root root??? ??? 14687 Aug 11 20:40 write_i2c ghpsdr3-alex always has been OK. 73 ... Sid. -- 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 From andrea.montefusco at gmail.com Mon Aug 11 14:04:08 2014 From: andrea.montefusco at gmail.com (andrea montefusco) Date: Mon, 11 Aug 2014 23:04:08 +0200 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <1407708969.5462.23.camel@Barossa> References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> <1407708969.5462.23.camel@Barossa> Message-ID: On Aug 11, 2014 12:16 AM, "Berndt Josef Wulf" wrote: > > G'day, > > A modified version of cuSDR can be downloaded from > >http://www.ping.net.au/20140126_cuSDR64src.tar.gz > > It requires QT5 and may not work with the current firmware change, so > your mileage may wary. Hi Berndt, That is a good news, especially for people trying to use cuSDR on Jetson board: together with Ken N9VV we compiled the original cuSDR but we didn't manage to achieve a proper working with the Qt 4.x. In any case, I just compiled your code with qt 5.3 on Ubuntu 12.04 (i5) and it works well (Metis 2.8, Mercury 3.4). *am* -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vbv at blueyonder.co.uk Mon Aug 11 17:29:04 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Tue, 12 Aug 2014 01:29:04 +0100 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> <53E8EA3D.9060807@blueyonder.co.uk> Message-ID: <53E95FD0.4000106@blueyonder.co.uk> Hi Steve and Kevin, Instead of the KV0S svn I use "svn co http://svn.tapr.org/repos_sdr_hpsdr/trunk/N6LYT/Qt" built without changes /usr/src/Qt/trunk # ls -l bin total 2484 -rwxr-xr-x 1 root root 1481425 Aug 11 20:33 QtDSPServer -rwxr-xr-x 1 root root?????? 396047 Aug 11 20:32 QtHPSDRServer -rwxr-xr-x 1 root root?????? 663150 Aug 11 20:34 QtRadio Building on openSUSE which uses lib64. libusb-1.0 is in /usr/include. Makefile changes ========== ghpsdr ---------- INCLUDES=-I. -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include\ -I/usr/include/gdk-pixbuf-2.0\ -I/usr/include/atk-1.0 -I/usr/include/cairo\ -I/usr/include/pango-1.0 -I/usr/include/glib-2.0\ -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1\ -I/usr/include/freetype2 -I/usr/include/libpng12 \ -I/usr/include/libusb-1.0 Built DttSP.tar.gz in ghpsdr directory LIBS=-L. -L/usr/src/openHPSDR/ghpsdr/DttSP -lDttSP -lpthread -lusb-1.0\ -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0\ -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lz\ -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lfftw3f slipstream:/usr/src/openHPSDR/ghpsdr # ls -l bin/ghpsdr -rwxr-xr-x 1 root root 1126746 Aug 11 20:47 ghpsdr ghpsdr3-alex always has been OK. 73 ... Sid. -- 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 From g3vbv at blueyonder.co.uk Mon Aug 11 17:39:58 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Tue, 12 Aug 2014 01:39:58 +0100 Subject: [hpsdr] 20140126_cuSDR64src In-Reply-To: References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> <1407708969.5462.23.camel@Barossa> Message-ID: <53E9625E.5070203@blueyonder.co.uk> No problems on openSUSE x86_64, built with Qt-5.3.1. 73 ... Sid. On 11/08/14 22:04, andrea montefusco wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > > On Aug 11, 2014 12:16 AM, "Berndt Josef Wulf" > wrote: > > > > G'day, > > > > A modified version of cuSDR can be downloaded from > > > >http://www.ping.net.au/20140126_cuSDR64src.tar.gz > > > > It requires QT5 and may not work with the current firmware change, so > > your mileage may wary. > > -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vbv at blueyonder.co.uk Tue Aug 12 12:46:15 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Tue, 12 Aug 2014 20:46:15 +0100 Subject: [hpsdr] 20140126_cuSDR64src In-Reply-To: <53E9625E.5070203@blueyonder.co.uk> References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> <1407708969.5462.23.camel@Barossa> <53E9625E.5070203@blueyonder.co.uk> Message-ID: <53EA6F07.8060000@blueyonder.co.uk> Hi Andrea, Just for fun I built it on the ODROID-U3 but have not got around to testing it. root at odroidu3:/a1/ANDREA/cuSDR64# file bin/cuSDR64 bin/cuSDR64: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=ad66531161d9dd1be3a83e4720c1436343b867ef, not stripped root at odroidu3:/a1/ANDREA/cuSDR64# cuSDR32 modified and built with qt-5.3.1 should also be no problem. 73 ... Sid. On 12/08/14 01:39, Sid Boyce wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > No problems on openSUSE x86_64, built with Qt-5.3.1. > 73 ... Sid. > > On 11/08/14 22:04, andrea montefusco wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> >> >> >> On Aug 11, 2014 12:16 AM, "Berndt Josef Wulf" > > wrote: >> > >> > G'day, >> > >> > A modified version of cuSDR can be downloaded from >> > >> >http://www.ping.net.au/20140126_cuSDR64src.tar.gz >> > >> > It requires QT5 and may not work with the current firmware change, so >> > your mileage may wary. >> >> > > -- > 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 > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gokoyev+k3it at gmail.com Thu Aug 14 07:14:26 2014 From: gokoyev+k3it at gmail.com (k3it) Date: Thu, 14 Aug 2014 10:14:26 -0400 Subject: [hpsdr] Updates to the Skimmer server interface DLL v14.8.13 Message-ID: An updated version of HermesIntf.dll Skimmer server interface for HPSDR is available at *https://sourceforge.net/projects/hermesintf/files/ * new h/w support: - Afedri SDR-net in HPSDR emulation mode (firmware 228e and higher) - N1GP RTL_hpsdr (see https://github.com/n1gp/rtl_hpsdr ) - up to seven receivers in Hermes depending on the firmware revision. Support of the latest v2.9 firmware (4 rcvrs) - additonal HPSDR variants (Angelia, Metis, etc) increased logging level in HermesIntf_log_file.txt Supported sample rates/receivers: 48/96/192 Khz Hermes: - Firmware version *1.8* (download from the dxatlas.com web site) - 7 receivers - Firmware version 2.4,2.5 - 5 receivers - Firmware version 2.9 - 4 receivers - Other fw revisions: defaults to 4 receivers Angelia: - 7 receivers Metis: - 4 receivers N1GP RTL dongle in HPSDR emulation mode: - up to 8 receivers, depending on the number of connected dongles Afedri SDR-NET single and dual channel in HPSDR emulation mode: - 1 or 2 receivers Please email if you run into any problems 73! Vasiliy K3IT -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrospopo at sbcglobal.net Mon Aug 11 09:38:50 2014 From: jrospopo at sbcglobal.net (Jim Rospopo) Date: Mon, 11 Aug 2014 11:38:50 -0500 Subject: [hpsdr] Newbie Question on computer and Munin Message-ID: <023201cfb582$bb967750$32c365f0$@sbcglobal.net> Newbie question, I just got the rest of the cards for my HPSDR. I was wondering what are the minimum requirements for the computer. I'll most likely be using the PowerSDR software or I may use it on my iMac with those programs. Are these programs optimized for the intel processors or will the AMD processors work equally well ? Also any minimum RAM requirements and or processor speeds ? Also, is there any more information on the Munin PA ? I know there was a group buy a while back. Are any kits still available from that buy. I also heard that TAPR was thinking of offering it as a kit. Is there any more information on that front. I'm sure as I proceed I'll have more questions. Excited to get this put together and operating. 73's Jim KE4CON -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa8k73 at gmail.com Fri Aug 15 19:23:24 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 15 Aug 2014 22:23:24 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/16 Message-ID: <53EEC09C.2040106@gmail.com> The 16/Aug TeamSpeak mp3 (61 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3511 > or < http://www.hamsdr.com/dnld.aspx > Only silence truncation editing was done on this recording. From phil at pharman.org Sun Aug 17 01:36:07 2014 From: phil at pharman.org (Phil Harman) Date: Sun, 17 Aug 2014 16:36:07 +0800 Subject: [hpsdr] Hermes manual update Message-ID: <33210BB5CEBB48C2BA7FC92CBE75EE0F@ShackPC2> All, There is an update to the Hermes User Manual (V1.18) available from: http://openhpsdr.org/documents.php This contains additional information on the use of J17 when an external supply is used. Thanks to Rob, VE3EW, for the updated information. 73 Phil...VK6PH --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at vspl.co.uk Sun Aug 17 09:37:01 2014 From: chris at vspl.co.uk (Chris Smith) Date: Sun, 17 Aug 2014 17:37:01 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 Message-ID: <20140817163704.A6AAD48278@diego.dreamhost.com> Hi Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. Eventually cuSDR64 built and I could run it on the TK1 It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? Exciting to be able to use my TK1 in anger. Cheers & 73 Chris G4NUX From wulf at ping.net.au Sun Aug 17 14:02:25 2014 From: wulf at ping.net.au (Berndt Josef Wulf) Date: Mon, 18 Aug 2014 06:32:25 +0930 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <20140817163704.A6AAD48278@diego.dreamhost.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <1408309345.3501.6.camel@Barossa> G'day Chris, The -j4 option defines the number of threads being used for the build process in this case 4. I use -j n where n is number of CPU cores available on the system +1. It significantly speeds up the building process on multi-core systems. cuSDR's CPU load is generally high including Intel based *nix systems. I never looked into this, as I still hoping for an updated version from Hermann. The chief reasons for me using cuSDR is that it runs under Linux/NetBSD and the many features that made using it a pleasure. 73, Berndt VK5ABN On Sun, 2014-08-17 at 17:37 +0100, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my > recently acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for > some years now, building the libraries from sources under Fedora Linux > & OSX. I found the published build instructions using git a bit > longwinded but eventually succeeded. Does anyone know what the -j4 > option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after > changing the symlink in /usr/bin so that qmake pointed to the Qt-5 > version in /usr/local/Qt-5/bin I could run qmake at the top level of > cuSDR to bring the Makefile up to date. I didn't do a make clean so > some .o files reported "wrong file type" but removing the 3 offending > .o files led me to the next problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 > https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz > ) and apart from configure requiring a couple of qualifiers ( > ./configure --enable-single --enable-shared ) that library built and > installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run > cuSDR on any platform before) but everything appeared to be working. My > Atlas hardware was correctly reported along with ancient f/w versions > and I could hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a > roller wheel in the shack so the only way I seem to be able to tune is > to drag the frequency bar under the display left-right. That is far too > crude to tune an individual QSO but got me some audio recognisable as a > contact. > > One thing which alarms me slightly is that the CPU usage reported is in > the range 152-175% I assume that is reporting that more than one core > (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web > page: http://openhpsdr.org Archives: > http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From g3vbv at blueyonder.co.uk Sun Aug 17 15:12:17 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Sun, 17 Aug 2014 23:12:17 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <20140817163704.A6AAD48278@diego.dreamhost.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <53F128C1.7040900@blueyonder.co.uk> Hi Chris, As mentioned - The first impression is that the TK1 is 64-bit, but it is quad-core 32-bit. It's still a powerful beast, CUDA ensures that. The next version apparently due later this year is dual-core 64-bit. 20140126_cuSDR64src.tar.gz comes with .o files in bld/o which are compiled x86_64 files, "make clean" will get rid of them, then do "make -j 4". Be aware that different distros, Fedora, openSUSE, Ubuntu etc. use different package names so you must refine your search terms. Typically all distros provide most stuff so no need to build core applications, libraries or utilities. Unless you need a library at a higher level than the distro provides, avoid building and installing what is already provided. You can create deep pits to fall into later, sometimes much later if you are not careful. Ubuntu -- apt-cache search fftw. Fedora -- yum search fftw. openSUSE -- zypper se fftw Don't be tempted to enter package names as they may appear in another distro. When in doubt shorten the search string, e.g There are no packages with fftw3 in the name in Fedora while there are many in openSUSE and Ubuntu but again the package names differ. # yum search fftw3 Loaded plugins: langpacks, refresh-packagekit Warning: No matches found for: fftw3 No matches found These are the fft libraries installed in Fedora 20. # rpm -qa|grep fft fftw-libs-quad-3.3.4-3.fc20.x86_64 fftw-libs-single-3.3.4-3.fc20.x86_64 fftw-3.3.4-3.fc20.x86_64 fftw-libs-3.3.4-3.fc20.x86_64 fftw-libs-double-3.3.4-3.fc20.x86_64 fftw-devel-3.3.4-3.fc20.x86_64 fftw-libs-long-3.3.4-3.fc20.x86_64 Building Qt5, recommend using the instructions for ghpsdr3-alex which work on any platform. The instructions on the wiki for building ghpsdr3-alex avoid the use of symlinks, e.g if qt5 is built in /home/fred - "export PATH=/home/fred/qt5/qtbase/bin:$PATH" sets it up to use qt5. # qmake -v QMake version 3.0 Using Qt version 5.3.1 in /home/fred/qt5/qtbase/lib 73 ... Sid. On 17/08/14 17:37, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. > > One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- 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 From chris at vspl.co.uk Sun Aug 17 20:47:21 2014 From: chris at vspl.co.uk (Chris Smith) Date: Mon, 18 Aug 2014 04:47:21 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <53F128C1.7040900@blueyonder.co.uk> References: <20140817163704.A6AAD48278@diego.dreamhost.com> <53F128C1.7040900@blueyonder.co.uk> Message-ID: <20140818035052.63DBD48319@diego.dreamhost.com> Hi Sid As I mentioned off list I'm not a fan of Debian based distros because I find apt so difficult to use compared to yum. But by widening my search pattern in apt-cache search I was able to find libfftw3, so I've removed the version I built from sources and installed the package. cuSDR builds OK so I'm happy with that. Regarding Qt5, I would normally add to PATH but wanted a quick and dirty fix so changing the symlink was favourite. :-) 73, Chris G4NUX Sent from my iPad > On 17 Aug 2014, at 23:12, Sid Boyce wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Chris, > As mentioned - The first impression is that the TK1 is 64-bit, but it is quad-core 32-bit. It's still a powerful beast, CUDA ensures that. > > The next version apparently due later this year is dual-core 64-bit. > > 20140126_cuSDR64src.tar.gz comes with .o files in bld/o which are compiled x86_64 files, "make clean" will get rid of them, then do "make -j 4". > > Be aware that different distros, Fedora, openSUSE, Ubuntu etc. use different package names so you must refine your search terms. > Typically all distros provide most stuff so no need to build core applications, libraries or utilities. > Unless you need a library at a higher level than the distro provides, avoid building and installing what is already provided. You can create deep pits to fall into later, sometimes much later if you are not careful. > > Ubuntu -- apt-cache search fftw. > Fedora -- yum search fftw. > openSUSE -- zypper se fftw > > Don't be tempted to enter package names as they may appear in another distro. When in doubt shorten the search string, e.g There are no packages with fftw3 in the name in Fedora while there are many in openSUSE and Ubuntu but again the package names differ. > # yum search fftw3 > Loaded plugins: langpacks, refresh-packagekit > Warning: No matches found for: fftw3 > No matches found > > These are the fft libraries installed in Fedora 20. > # rpm -qa|grep fft > fftw-libs-quad-3.3.4-3.fc20.x86_64 > fftw-libs-single-3.3.4-3.fc20.x86_64 > fftw-3.3.4-3.fc20.x86_64 > fftw-libs-3.3.4-3.fc20.x86_64 > fftw-libs-double-3.3.4-3.fc20.x86_64 > fftw-devel-3.3.4-3.fc20.x86_64 > fftw-libs-long-3.3.4-3.fc20.x86_64 > > Building Qt5, recommend using the instructions for ghpsdr3-alex which work on any platform. > The instructions on the wiki for building ghpsdr3-alex avoid the use of symlinks, e.g if qt5 is built in /home/fred - "export PATH=/home/fred/qt5/qtbase/bin:$PATH" sets it up to use qt5. > # qmake -v > QMake version 3.0 > Using Qt version 5.3.1 in /home/fred/qt5/qtbase/lib > 73 ... Sid. > >> On 17/08/14 17:37, Chris Smith wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi >> >> Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. >> >> Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? >> >> Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. >> >> I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. >> >> Eventually cuSDR64 built and I could run it on the TK1 >> >> It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. >> >> The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. >> >> One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? >> >> Exciting to be able to use my TK1 in anger. >> >> Cheers & 73 >> >> Chris G4NUX >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > -- > 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 > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From g3vbv at blueyonder.co.uk Mon Aug 18 03:30:39 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 18 Aug 2014 11:30:39 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <53f1781b.ef21700a.2a89.ffff8ac3SMTPIN_ADDED_MISSING@mx.google.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> <53F128C1.7040900@blueyonder.co.uk> <53f1781b.ef21700a.2a89.ffff8ac3SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <53F1D5CF.4010805@blueyonder.co.uk> Hi Chris, I use whatever is before me, I have had to do that for decades working with 12 or more different OS's - yum search, zypper search/se, apt-*, aptitude search, pacman -S, not much of a difference between them really. I also stash tons of executable scripts that lighten the key pounding load. I have them in /usr/local/mybin which is permanently added to PATH. lancelot at slipstream:~> cat /usr/local/mybin/BUILD_GNURADIO #!/bin/sh cmake -DPYTHON_EXECUTABLE=/usr/bin/python2.7 -DPYTHON_INCLUDE_DIR=/usr/include/python2.7 -DPYTHON_LIBRARY=/usr/lib64/libpython2.7.so -DCMAKE_INSTALL_PREFIX=/usr . lancelot at slipstream:~> cat /usr/local/mybin/QUARTUS #!/bin/sh cd /home/lancelot/altera/13.0/quartus/bin/ ./quartus& lancelot at slipstream:~> cat /usr/local/mybin/HERMES_384K #!/bin/sh hpsdr-server --hermes 255 --samplerate 384000 --interface enp3s0 & There is only one OS I have ever shied away from as I was never required to use it to earn a daily crust. The one with the fur coat and no under garments. 73 ... Sid. On 18/08/14 04:47, Chris Smith wrote: > Hi Sid > > As I mentioned off list I'm not a fan of Debian based distros because I find apt so difficult to use compared to yum. But by widening my search pattern in apt-cache search I was able to find libfftw3, so I've removed the version I built from sources and installed the package. cuSDR builds OK so I'm happy with that. > > Regarding Qt5, I would normally add to PATH but wanted a quick and dirty fix so changing the symlink was favourite. :-) > > 73, Chris G4NUX > > Sent from my iPad > >> On 17 Aug 2014, at 23:12, Sid Boyce wrote: >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Chris, >> As mentioned - The first impression is that the TK1 is 64-bit, but it is quad-core 32-bit. It's still a powerful beast, CUDA ensures that. >> >> The next version apparently due later this year is dual-core 64-bit. >> >> 20140126_cuSDR64src.tar.gz comes with .o files in bld/o which are compiled x86_64 files, "make clean" will get rid of them, then do "make -j 4". >> >> Be aware that different distros, Fedora, openSUSE, Ubuntu etc. use different package names so you must refine your search terms. >> Typically all distros provide most stuff so no need to build core applications, libraries or utilities. >> Unless you need a library at a higher level than the distro provides, avoid building and installing what is already provided. You can create deep pits to fall into later, sometimes much later if you are not careful. >> >> Ubuntu -- apt-cache search fftw. >> Fedora -- yum search fftw. >> openSUSE -- zypper se fftw >> >> Don't be tempted to enter package names as they may appear in another distro. When in doubt shorten the search string, e.g There are no packages with fftw3 in the name in Fedora while there are many in openSUSE and Ubuntu but again the package names differ. >> # yum search fftw3 >> Loaded plugins: langpacks, refresh-packagekit >> Warning: No matches found for: fftw3 >> No matches found >> >> These are the fft libraries installed in Fedora 20. >> # rpm -qa|grep fft >> fftw-libs-quad-3.3.4-3.fc20.x86_64 >> fftw-libs-single-3.3.4-3.fc20.x86_64 >> fftw-3.3.4-3.fc20.x86_64 >> fftw-libs-3.3.4-3.fc20.x86_64 >> fftw-libs-double-3.3.4-3.fc20.x86_64 >> fftw-devel-3.3.4-3.fc20.x86_64 >> fftw-libs-long-3.3.4-3.fc20.x86_64 >> >> Building Qt5, recommend using the instructions for ghpsdr3-alex which work on any platform. >> The instructions on the wiki for building ghpsdr3-alex avoid the use of symlinks, e.g if qt5 is built in /home/fred - "export PATH=/home/fred/qt5/qtbase/bin:$PATH" sets it up to use qt5. >> # qmake -v >> QMake version 3.0 >> Using Qt version 5.3.1 in /home/fred/qt5/qtbase/lib >> 73 ... Sid. >> >>> On 17/08/14 17:37, Chris Smith wrote: >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> Hi >>> >>> Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. >>> >>> Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? >>> >>> Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. >>> >>> I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. >>> >>> Eventually cuSDR64 built and I could run it on the TK1 >>> >>> It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. >>> >>> The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. >>> >>> One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? >>> >>> Exciting to be able to use my TK1 in anger. >>> >>> Cheers & 73 >>> >>> Chris G4NUX >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> -- >> 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 >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 From hvh.net at gmail.com Mon Aug 18 04:24:23 2014 From: hvh.net at gmail.com (Hermann) Date: Mon, 18 Aug 2014 13:24:23 +0200 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <20140817163704.A6AAD48278@diego.dreamhost.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: Dear Chris, congratulations! What I noticed last year when I did some experiments with cuSDR on my Gentoo box is also a higher CPU load compared to a Windows box. I did not took a closer look at yet where this might come from, but it could depend on many things. I will compile cuSDR on my Jetson in short (I hope so, hi) and will take a closer look at. Maybe the strategy of advising/generating threads in cuSDR has to be modified to suit the Linux scheduler, but this is purely speculative for now. 73, Hermann DL3HVH On Sun, Aug 17, 2014 at 6:37 PM, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my recently > acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for some > years now, building the libraries from sources under Fedora Linux & OSX. I > found the published build instructions using git a bit longwinded but > eventually succeeded. Does anyone know what the -j4 option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after > changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version > in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring > the Makefile up to date. I didn't do a make clean so some .o files reported > "wrong file type" but removing the 3 offending .o files led me to the next > problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 > https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz > ) and apart from configure requiring a couple of qualifiers ( ./configure > --enable-single --enable-shared ) that library built and installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run cuSDR > on any platform before) but everything appeared to be working. My Atlas > hardware was correctly reported along with ancient f/w versions and I could > hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a > roller wheel in the shack so the only way I seem to be able to tune is to > drag the frequency bar under the display left-right. That is far too crude > to tune an individual QSO but got me some audio recognisable as a contact. > > One thing which alarms me slightly is that the CPU usage reported is in > the range 152-175% I assume that is reporting that more than one core > (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at vspl.co.uk Mon Aug 18 06:32:16 2014 From: chris at vspl.co.uk (Chris Smith) Date: Mon, 18 Aug 2014 14:32:16 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <20140818133219.75557481E0@diego.dreamhost.com> Hi Herman I'm so encouraged by the success of this venture that I'm going to build cuSDR64 on my HPSDR dual-boot system - WinXP/F19. I'd like to be shot of Windows for good. PowerSDR is the only piece of software that I currently use that needs Windows. I'll let you know how I get on there. 73, Chris G4NUX On 18 Aug 2014, at 12:24, Hermann wrote: > Dear Chris, > > congratulations! What I noticed last year when I did some experiments with cuSDR on my Gentoo box is also a higher CPU load compared to a Windows box. I did not took a closer look at yet where this might come from, but it could depend on many things. I will compile cuSDR on my Jetson in short (I hope so, hi) and will take a closer look at. Maybe the strategy of advising/generating threads in cuSDR has to be modified to suit the Linux scheduler, but this is purely speculative for now. > > > 73, Hermann DL3HVH > > > On Sun, Aug 17, 2014 at 6:37 PM, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. > > One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From irbsurfing at yahoo.co.uk Tue Aug 19 13:04:06 2014 From: irbsurfing at yahoo.co.uk (Andrew) Date: Tue, 19 Aug 2014 21:04:06 +0100 Subject: [hpsdr] Wideband waterfall display Message-ID: <1408478646.90961.YahooMailNeo@web171206.mail.ir2.yahoo.com> Hi, Just wondering if anyone knows of a piece of software that can show a 0-55MHz wideband waterfall display with Hermes etc? I know Kiss Konsole and CuSDR have a wideband pan-adapter, but not a waterfall as far as I know. Thanks, Andrew G4XZL -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvh.net at gmail.com Tue Aug 19 13:09:40 2014 From: hvh.net at gmail.com (Hermann) Date: Tue, 19 Aug 2014 22:09:40 +0200 Subject: [hpsdr] Wideband waterfall display In-Reply-To: <1408478646.90961.YahooMailNeo@web171206.mail.ir2.yahoo.com> References: <1408478646.90961.YahooMailNeo@web171206.mail.ir2.yahoo.com> Message-ID: Hi Andrew, Next version of cuSDR has a wideband waterfall display. In the beta this is already working. 73, Hermann DL3HVH Sent from my Nexus 5 On Aug 19, 2014 10:04 PM, "Andrew" wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > Hi, > Just wondering if anyone knows of a piece of software that can show a > 0-55MHz wideband waterfall display with Hermes etc? > I know Kiss Konsole and CuSDR have a wideband pan-adapter, but not a > waterfall as far as I know. > Thanks, > Andrew > G4XZL > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at pharman.org Wed Aug 20 00:31:26 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 15:31:26 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. In order to open the SDR world to those with PC software skills we are in the process of developing a new SDR architecture. This architecture digitises the entire 0 to 30MHz radio spectrum in real time and passes the 'raw' samples directly to an associated computer. This computer then calculates the FFT of the raw samples and subsequently processes the result as the user requires. This is not a totally new concept since both the cuSDR and KISS Konsole software uses raw ADC samples to provide the wideband bandscope displays. However, for this requirement the FFT only needs to be done at the bandscope update rate of a few 10's of times per second, which hardly taxes a modern PC at all. The new concept requires that we take the FFT of all samples in real-time. This has been possible in the past - if you had access to a Cray super computer! Well now we do have access to very low cost computers that provide the processing power we need. One example of this is the new Nvidia Jetson TK1 single board computer. At a cost of $192 this board contains four ARM CPUs plus 192 CUDA processors. More details of this remarkable board can be found here: https://developer.nvidia.com/jetson-tk1 Since the CUDA cores can process data in parallel, we can use these to perform the high speed FFT. John, G0ORX, has written preliminary code for the Jetson board and has confirmed that it has the necessary performance we require. The test environment consisted of a Jetson board connected via Gigabit Ethernet to an Angelia board. A special version of FPGA code was written for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the Jetson board. We used raw Ethernet frames over the Gigabit link, in order to maximise the link bandwidth, since we require a sustained 983Mbps transfer rate. Whilst it's still early days, and there is much more to be done, this critical early success does indicate that this new architecture has a very promising future. The Jetson board is taking the role of an 'SDR Server' which I have written about in the past. In which case what benefits does this new architecture provide to openHPSR? 1. The FPGA code is greatly simplified, is easier to write and maintain, and hence uses a small percentage of the space available with a subsequent reduction in power consumption. 2. The protocol between the SDR hardware and the SDR Server is greatly simplified since the SDR hardware only has to connect to a single, dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer required. The SDR Server simply needs to know the MAC address of the SDR hardware in order to communicate. It should be possible for a single SDR hardware board to feed multiple SDR Servers, but that's something for the future. 3. Virtually all the signal processing is undertaken on the associated single board computer (SBC) or (suitable) PC. If sufficient processing power is available then the GUI can run on the same SBC. Alternatively the user's normal PC (which does not require to be high performance since it does not do any significant digital signal processing) or a Tablet, cell phone etc could be used. 4. Many more users have the necessary skills and experience to support, maintain and further develop the code. New features are added to the SDR Server code rather than the FPGA code. 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA and/or power supply restrictions may have limited adding new features. 6. Future hardware upgrades will be to the associated SBC where faster and lower cost options can be expected. Nvidia have already indicated that a 64 bit board will be available in the near future. 7. Remote access to an SDR via the Internet will enable multiple users to share the SDR with each selecting their desired frequency, bandwidth and mode. There are other potential benefits relating to simpler and lower cost SDR hardware, but that is for the future. For want of a name we are calling this new architecture 'Direct Fourier Conversion' (DFC). For those that are already experimenting with the Jetson board we do intend to release the DFC FPGA code for both Angelia and Hermes boards and I will advise when, and where, this is available. John's code is presently not available, so please don't pester him, but as soon as it reaches Beta stage it will be released. Please join me in congratulating John on this exciting development. 73 Phil....VK6PH From chris at vspl.co.uk Wed Aug 20 00:42:58 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 08:42:58 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <20140820074302.6AB7048864@diego.dreamhost.com> Hi Phil I had a feeling, when I saw your paper and Hermann's at Friedrischafen, that DFC was the way things were going. Which is why I jumped on the TK1 bandwagon. Will there ever be a way of using the Mercury front end to supply the raw packets, perhaps with a bespoke daughter board? Congrats to John whom I had the pleasure of speaking to at Friedrischafen. I'm sure we all look forward to the new era of SDR in the amateur radio arena. Cheers & 73 Chris G4NUX On 20 Aug 2014, at 08:31, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From roland.etienne at free.fr Wed Aug 20 00:48:52 2014 From: roland.etienne at free.fr (Roland Etienne) Date: Wed, 20 Aug 2014 09:48:52 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <0EDA19C686524970B4E75CD8483127AE@F8CHKAtom> Hi Phil, Very exciting news! Congrats to John and all of you, crazy programmers! how do you find the time to do all that job ?? Thanks a lot for the fun you're giving us! 73, Roland F8CHK > -----Message d'origine----- > De?: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] De la part de Phil > Harman > Envoy??: mercredi 20 ao?t 2014 09:31 > ??: hpsdr at lists.openhpsdr.org > Objet?: [hpsdr] openHPSDR at the forefront of SDR development > > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > .... > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > .... > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr- > openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From phil at pharman.org Wed Aug 20 01:22:48 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 16:22:48 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: Hi Chris, The limitation of using the Mercury board together with Metis is the bandwidth of the Alex bus. If would could couple the two boards together in a suitable way then we can use the existing Mercury board. 73 Phil...VK6PH > Hi Phil > > I had a feeling, when I saw your paper and Hermann's at Friedrischafen, > that DFC was the way things were going. Which is why I jumped on the TK1 > bandwagon. > > Will there ever be a way of using the Mercury front end to supply the raw > packets, perhaps with a bespoke daughter board? > > Congrats to John whom I had the pleasure of speaking to at Friedrischafen. > I'm sure we all look forward to the new era of SDR in the amateur radio > arena. > > Cheers & 73 > > Chris G4NUX > > On 20 Aug 2014, at 08:31, Phil Harman wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> I'm delighted to be able to report that we have been able to develop, to >> proof-of-concept stage, a new SDR architecture. >> >> Current SDRs use the software equivalent of zero IF techniques, i.e. >> DDC, >> in order to provide (multiple) receivers. Whist this is quite >> effective, >> much of the initial DSP work is done using FPGAs, or a combination of >> FPGA >> plus dedicated DSP chips and microprocessors, rather than totally within >> the PC. >> >> As more complex features are added, the size and complexity of the FPGA >> and DSP code increases. The skills to write, debug and maintain this >> code >> is only available via a small percentage of software engineers, or >> enthusiasts, in comparison to those able to write code for PC based >> hardware. >> >> In order to open the SDR world to those with PC software skills we are >> in >> the process of developing a new SDR architecture. >> >> This architecture digitises the entire 0 to 30MHz radio spectrum in real >> time and passes the 'raw' samples directly to an associated computer. >> >> This computer then calculates the FFT of the raw samples and >> subsequently >> processes the result as the user requires. >> >> This is not a totally new concept since both the cuSDR and KISS Konsole >> software uses raw ADC samples to provide the wideband bandscope >> displays. >> >> However, for this requirement the FFT only needs to be done at the >> bandscope update rate of a few 10's of times per second, which hardly >> taxes a modern PC at all. >> >> The new concept requires that we take the FFT of all samples in >> real-time. >> >> This has been possible in the past - if you had access to a Cray super >> computer! >> >> Well now we do have access to very low cost computers that provide the >> processing power we need. One example of this is the new Nvidia Jetson >> TK1 single board computer. At a cost of $192 this board contains four >> ARM >> CPUs plus 192 CUDA processors. >> >> More details of this remarkable board can be found here: >> >> https://developer.nvidia.com/jetson-tk1 >> >> Since the CUDA cores can process data in parallel, we can use these to >> perform the high speed FFT. >> >> John, G0ORX, has written preliminary code for the Jetson board and has >> confirmed that it has the necessary performance we require. >> >> The test environment consisted of a Jetson board connected via Gigabit >> Ethernet to an Angelia board. A special version of FPGA code was >> written >> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >> the >> Jetson board. >> >> We used raw Ethernet frames over the Gigabit link, in order to maximise >> the link bandwidth, since we require a sustained 983Mbps transfer rate. >> >> Whilst it's still early days, and there is much more to be done, this >> critical early success does indicate that this new architecture has a >> very >> promising future. >> >> The Jetson board is taking the role of an 'SDR Server' which I have >> written about in the past. >> >> In which case what benefits does this new architecture provide to >> openHPSR? >> >> 1. The FPGA code is greatly simplified, is easier to write and maintain, >> and hence uses a small percentage of the space available with a >> subsequent >> reduction in power consumption. >> >> 2. The protocol between the SDR hardware and the SDR Server is greatly >> simplified since the SDR hardware only has to connect to a single, >> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >> required. The SDR Server simply needs to know the MAC address of the >> SDR >> hardware in order to communicate. It should be possible for a single >> SDR >> hardware board to feed multiple SDR Servers, but that's something for >> the >> future. >> >> 3. Virtually all the signal processing is undertaken on the associated >> single board computer (SBC) or (suitable) PC. If sufficient processing >> power is available then the GUI can run on the same SBC. Alternatively >> the >> user's normal PC (which does not require to be high performance since it >> does not do any significant digital signal processing) or a Tablet, cell >> phone etc could be used. >> >> 4. Many more users have the necessary skills and experience to support, >> maintain and further develop the code. New features are added to the SDR >> Server code rather than the FPGA code. >> >> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >> FPGA >> and/or power supply restrictions may have limited adding new features. >> >> 6. Future hardware upgrades will be to the associated SBC where faster >> and >> lower cost options can be expected. Nvidia have already indicated that >> a >> 64 bit board will be available in the near future. >> >> 7. Remote access to an SDR via the Internet will enable multiple users >> to >> share the SDR with each selecting their desired frequency, bandwidth and >> mode. >> >> There are other potential benefits relating to simpler and lower cost >> SDR >> hardware, but that is for the future. >> >> For want of a name we are calling this new architecture 'Direct Fourier >> Conversion' (DFC). >> >> For those that are already experimenting with the Jetson board we do >> intend to release the DFC FPGA code for both Angelia and Hermes boards >> and >> I will advise when, and where, this is available. >> >> John's code is presently not available, so please don't pester him, but >> as >> soon as it reaches Beta stage it will be released. >> >> Please join me in congratulating John on this exciting development. >> >> 73 Phil....VK6PH >> >> >> >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > From dc6ny at gmx.de Wed Aug 20 01:48:31 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Wed, 20 Aug 2014 10:48:31 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <000001cfbc53$85bf7be0$913e73a0$@de> Hi Phil, Congratulations. Maybe a stupid question: Current bottleneck is the 1 Gbit/s LAN connection that makes a decimation by factor 2 necessary or limits the frequency range to 33MHz, i.e. we lose 6m band at least as raw I/Q. Is there no (economic) way to get the LAN connection faster? 14 and 16 Bit ADC/DACs are getting faster and low-jitter sampling oscillators up to 300MHz are available, hence a lot of nice applications are imaginable, hi. 73, Helmut, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von Phil Harman Gesendet: Mittwoch, 20. August 2014 09:31 An: hpsdr at lists.openhpsdr.org Betreff: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. In order to open the SDR world to those with PC software skills we are in the process of developing a new SDR architecture. This architecture digitises the entire 0 to 30MHz radio spectrum in real time and passes the 'raw' samples directly to an associated computer. This computer then calculates the FFT of the raw samples and subsequently processes the result as the user requires. This is not a totally new concept since both the cuSDR and KISS Konsole software uses raw ADC samples to provide the wideband bandscope displays. However, for this requirement the FFT only needs to be done at the bandscope update rate of a few 10's of times per second, which hardly taxes a modern PC at all. The new concept requires that we take the FFT of all samples in real-time. This has been possible in the past - if you had access to a Cray super computer! Well now we do have access to very low cost computers that provide the processing power we need. One example of this is the new Nvidia Jetson TK1 single board computer. At a cost of $192 this board contains four ARM CPUs plus 192 CUDA processors. More details of this remarkable board can be found here: https://developer.nvidia.com/jetson-tk1 Since the CUDA cores can process data in parallel, we can use these to perform the high speed FFT. John, G0ORX, has written preliminary code for the Jetson board and has confirmed that it has the necessary performance we require. The test environment consisted of a Jetson board connected via Gigabit Ethernet to an Angelia board. A special version of FPGA code was written for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the Jetson board. We used raw Ethernet frames over the Gigabit link, in order to maximise the link bandwidth, since we require a sustained 983Mbps transfer rate. Whilst it's still early days, and there is much more to be done, this critical early success does indicate that this new architecture has a very promising future. The Jetson board is taking the role of an 'SDR Server' which I have written about in the past. In which case what benefits does this new architecture provide to openHPSR? 1. The FPGA code is greatly simplified, is easier to write and maintain, and hence uses a small percentage of the space available with a subsequent reduction in power consumption. 2. The protocol between the SDR hardware and the SDR Server is greatly simplified since the SDR hardware only has to connect to a single, dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer required. The SDR Server simply needs to know the MAC address of the SDR hardware in order to communicate. It should be possible for a single SDR hardware board to feed multiple SDR Servers, but that's something for the future. 3. Virtually all the signal processing is undertaken on the associated single board computer (SBC) or (suitable) PC. If sufficient processing power is available then the GUI can run on the same SBC. Alternatively the user's normal PC (which does not require to be high performance since it does not do any significant digital signal processing) or a Tablet, cell phone etc could be used. 4. Many more users have the necessary skills and experience to support, maintain and further develop the code. New features are added to the SDR Server code rather than the FPGA code. 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA and/or power supply restrictions may have limited adding new features. 6. Future hardware upgrades will be to the associated SBC where faster and lower cost options can be expected. Nvidia have already indicated that a 64 bit board will be available in the near future. 7. Remote access to an SDR via the Internet will enable multiple users to share the SDR with each selecting their desired frequency, bandwidth and mode. There are other potential benefits relating to simpler and lower cost SDR hardware, but that is for the future. For want of a name we are calling this new architecture 'Direct Fourier Conversion' (DFC). For those that are already experimenting with the Jetson board we do intend to release the DFC FPGA code for both Angelia and Hermes boards and I will advise when, and where, this is available. John's code is presently not available, so please don't pester him, but as soon as it reaches Beta stage it will be released. Please join me in congratulating John on this exciting development. 73 Phil....VK6PH _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From chris at vspl.co.uk Wed Aug 20 01:48:56 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 09:48:56 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <20140820084900.495FC4861E@diego.dreamhost.com> Hi Phil I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) Cheers Chris On 20 Aug 2014, at 09:22, "Phil Harman" wrote: > Hi Chris, > > The limitation of using the Mercury board together with Metis is the > bandwidth of the Alex bus. > > If would could couple the two boards together in a suitable way then we > can use the existing Mercury board. > > 73 Phil...VK6PH > > >> Hi Phil >> >> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >> that DFC was the way things were going. Which is why I jumped on the TK1 >> bandwagon. >> >> Will there ever be a way of using the Mercury front end to supply the raw >> packets, perhaps with a bespoke daughter board? >> >> Congrats to John whom I had the pleasure of speaking to at Friedrischafen. >> I'm sure we all look forward to the new era of SDR in the amateur radio >> arena. >> >> Cheers & 73 >> >> Chris G4NUX >> >> On 20 Aug 2014, at 08:31, Phil Harman wrote: >> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> All, >>> >>> I'm delighted to be able to report that we have been able to develop, to >>> proof-of-concept stage, a new SDR architecture. >>> >>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>> DDC, >>> in order to provide (multiple) receivers. Whist this is quite >>> effective, >>> much of the initial DSP work is done using FPGAs, or a combination of >>> FPGA >>> plus dedicated DSP chips and microprocessors, rather than totally within >>> the PC. >>> >>> As more complex features are added, the size and complexity of the FPGA >>> and DSP code increases. The skills to write, debug and maintain this >>> code >>> is only available via a small percentage of software engineers, or >>> enthusiasts, in comparison to those able to write code for PC based >>> hardware. >>> >>> In order to open the SDR world to those with PC software skills we are >>> in >>> the process of developing a new SDR architecture. >>> >>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>> time and passes the 'raw' samples directly to an associated computer. >>> >>> This computer then calculates the FFT of the raw samples and >>> subsequently >>> processes the result as the user requires. >>> >>> This is not a totally new concept since both the cuSDR and KISS Konsole >>> software uses raw ADC samples to provide the wideband bandscope >>> displays. >>> >>> However, for this requirement the FFT only needs to be done at the >>> bandscope update rate of a few 10's of times per second, which hardly >>> taxes a modern PC at all. >>> >>> The new concept requires that we take the FFT of all samples in >>> real-time. >>> >>> This has been possible in the past - if you had access to a Cray super >>> computer! >>> >>> Well now we do have access to very low cost computers that provide the >>> processing power we need. One example of this is the new Nvidia Jetson >>> TK1 single board computer. At a cost of $192 this board contains four >>> ARM >>> CPUs plus 192 CUDA processors. >>> >>> More details of this remarkable board can be found here: >>> >>> https://developer.nvidia.com/jetson-tk1 >>> >>> Since the CUDA cores can process data in parallel, we can use these to >>> perform the high speed FFT. >>> >>> John, G0ORX, has written preliminary code for the Jetson board and has >>> confirmed that it has the necessary performance we require. >>> >>> The test environment consisted of a Jetson board connected via Gigabit >>> Ethernet to an Angelia board. A special version of FPGA code was >>> written >>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>> the >>> Jetson board. >>> >>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>> >>> Whilst it's still early days, and there is much more to be done, this >>> critical early success does indicate that this new architecture has a >>> very >>> promising future. >>> >>> The Jetson board is taking the role of an 'SDR Server' which I have >>> written about in the past. >>> >>> In which case what benefits does this new architecture provide to >>> openHPSR? >>> >>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>> and hence uses a small percentage of the space available with a >>> subsequent >>> reduction in power consumption. >>> >>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>> simplified since the SDR hardware only has to connect to a single, >>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>> required. The SDR Server simply needs to know the MAC address of the >>> SDR >>> hardware in order to communicate. It should be possible for a single >>> SDR >>> hardware board to feed multiple SDR Servers, but that's something for >>> the >>> future. >>> >>> 3. Virtually all the signal processing is undertaken on the associated >>> single board computer (SBC) or (suitable) PC. If sufficient processing >>> power is available then the GUI can run on the same SBC. Alternatively >>> the >>> user's normal PC (which does not require to be high performance since it >>> does not do any significant digital signal processing) or a Tablet, cell >>> phone etc could be used. >>> >>> 4. Many more users have the necessary skills and experience to support, >>> maintain and further develop the code. New features are added to the SDR >>> Server code rather than the FPGA code. >>> >>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>> FPGA >>> and/or power supply restrictions may have limited adding new features. >>> >>> 6. Future hardware upgrades will be to the associated SBC where faster >>> and >>> lower cost options can be expected. Nvidia have already indicated that >>> a >>> 64 bit board will be available in the near future. >>> >>> 7. Remote access to an SDR via the Internet will enable multiple users >>> to >>> share the SDR with each selecting their desired frequency, bandwidth and >>> mode. >>> >>> There are other potential benefits relating to simpler and lower cost >>> SDR >>> hardware, but that is for the future. >>> >>> For want of a name we are calling this new architecture 'Direct Fourier >>> Conversion' (DFC). >>> >>> For those that are already experimenting with the Jetson board we do >>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>> and >>> I will advise when, and where, this is available. >>> >>> John's code is presently not available, so please don't pester him, but >>> as >>> soon as it reaches Beta stage it will be released. >>> >>> Please join me in congratulating John on this exciting development. >>> >>> 73 Phil....VK6PH >>> >>> >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: >>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> >> > From meijer.ha at home.nl Wed Aug 20 01:58:26 2014 From: meijer.ha at home.nl (H.A.Meijer) Date: Wed, 20 Aug 2014 10:58:26 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F46332.9040601@home.nl> Phil Harman schreef op 20-8-2014 om 9:31: > ***** High Performance Software Defined Radio Discussion List ***** > > > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > Hi, I'm just a "end-user" and not a software engineer, so it's not very easy, for me, to understand all of this. Does it mean that that this "new board" is connected between your sdr transceiver (hermes etc) and your PC?. I would rater like a 'stand-alone' and 'High Performance' solution for better DSP functionality etc, and to get rid of my pc, then an extra board that just needs more soft- and firmware.... But I understand that this is very exiting for software engineers, so good luck. Bert PA2XHF --- Dit e-mailbericht bevat geen virussen en malware omdat avast! Antivirus-bescherming actief is. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dc6ny at gmx.de Wed Aug 20 02:09:52 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Wed, 20 Aug 2014 11:09:52 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F46332.9040601@home.nl> References: <53F46332.9040601@home.nl> Message-ID: <000c01cfbc56$808c9560$81a5c020$@de> Hi Bert, please see Phil's presentation 'Further prospective of HPSDR' at http://openhpsdr.org/publications.php and you will collect a lot of important info. 73, Helmut, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von H.A.Meijer Gesendet: Mittwoch, 20. August 2014 10:58 An: hpsdr at lists.openhpsdr.org Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** From ksyverud at broadpark.no Wed Aug 20 02:51:45 2014 From: ksyverud at broadpark.no (Kjell Syverud) Date: Wed, 20 Aug 2014 11:51:45 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F46FB1.2050304@broadpark.no> Hi Phil. Nice to hear you can confirm the "DFC" as you presented it in Friedrichshafen. One question, may be you commented it in Friedrichshafen, but i can not remember: Will it be possible to cover 30 to 60 MHz ? 73 LA9CY/Kjell From phil at pharman.org Wed Aug 20 04:15:36 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 19:15:36 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F46332.9040601@home.nl> References: <53F46332.9040601@home.nl> Message-ID: <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> Hi Bert, Yes, as we are today the ?new board? is connected between your SDR hardware and your PC. It may be possible to run both the SDR server and Client GUI software on the one SBC or PC. Its a little early yet to know if the Jetson board is capable of doing this. If so, then with your SDR hardware you would have a dedicated SDR that does not require an additional PC. This could all be packaged into a case with a suitable touch screen etc. You can always do that today by using a suitable SBC that will run Windows. 73 Phil...VK6PH Hi, I'm just a "end-user" and not a software engineer, so it's not very easy, for me, to understand all of this. Does it mean that that this "new board" is connected between your sdr transceiver (hermes etc) and your PC?. I would rater like a 'stand-alone' and 'High Performance' solution for better DSP functionality etc, and to get rid of my pc, then an extra board that just needs more soft- and firmware.... But I understand that this is very exiting for software engineers, so good luck. Bert PA2XHF -------------------------------------------------------------------------------- Dit e-mailbericht bevat geen virussen en malware omdat avast! Antivirus actief is. -------------------------------------------------------------------------------- _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at pharman.org Wed Aug 20 04:28:08 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 19:28:08 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F46FB1.2050304@broadpark.no> References: <53F46FB1.2050304@broadpark.no> Message-ID: <0EB6587E8CAE411C8E61A6B0215E7070@ShackPC2> Hi Kjell, Initially its not going to be possible to cover 0 to 55MHz of spectrum since with 16 bits of ADC data that would exceed the capacity of the Gigabit channel. We could reduce the ADC data to 8 bits but that would hardly meet the 'High Performance' requirement! We can still use 6m since this will alias into the 0-30MHz range, but we can't do both at the same time. We still have 16Mbps 'spare' in the Ethernet bandwidth so we may be able to include 6m using a conventional DDC. Still early days, we can use the mini PCIe interface on the Jetson board to interface to the ADC/DAC in order to run at faster sampling rates. At the moment we don't know how much spare processing capacity we have on board so still lots more tests to run. 73 Phil...VK6PH -----Original Message----- From: Kjell Syverud Sent: Wednesday, August 20, 2014 5:51 PM To: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Hi Phil. Nice to hear you can confirm the "DFC" as you presented it in Friedrichshafen. One question, may be you commented it in Friedrichshafen, but i can not remember: Will it be possible to cover 30 to 60 MHz ? 73 LA9CY/Kjell _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From phil at pharman.org Wed Aug 20 04:37:31 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 19:37:31 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> Hi Chris. Alternatively, you could make a small PCB that plugged into J5 on Mercury that held the PHY, 25MHz clock and Ethernet socket. Since you no longer need any DDC code in the FPGA you would have plenty of room to house the raw Ethernet code. 'Weekend Project' anyone ? 73 Phil....VK6PH -----Original Message----- From: Chris Smith Sent: Wednesday, August 20, 2014 4:48 PM To: phil at pharman.org Cc: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development Hi Phil I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) Cheers Chris On 20 Aug 2014, at 09:22, "Phil Harman" wrote: > Hi Chris, > > The limitation of using the Mercury board together with Metis is the > bandwidth of the Alex bus. > > If would could couple the two boards together in a suitable way then we > can use the existing Mercury board. > > 73 Phil...VK6PH > > >> Hi Phil >> >> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >> that DFC was the way things were going. Which is why I jumped on the TK1 >> bandwagon. >> >> Will there ever be a way of using the Mercury front end to supply the raw >> packets, perhaps with a bespoke daughter board? >> >> Congrats to John whom I had the pleasure of speaking to at >> Friedrischafen. >> I'm sure we all look forward to the new era of SDR in the amateur radio >> arena. >> >> Cheers & 73 >> >> Chris G4NUX >> >> On 20 Aug 2014, at 08:31, Phil Harman wrote: >> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> All, >>> >>> I'm delighted to be able to report that we have been able to develop, to >>> proof-of-concept stage, a new SDR architecture. >>> >>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>> DDC, >>> in order to provide (multiple) receivers. Whist this is quite >>> effective, >>> much of the initial DSP work is done using FPGAs, or a combination of >>> FPGA >>> plus dedicated DSP chips and microprocessors, rather than totally within >>> the PC. >>> >>> As more complex features are added, the size and complexity of the FPGA >>> and DSP code increases. The skills to write, debug and maintain this >>> code >>> is only available via a small percentage of software engineers, or >>> enthusiasts, in comparison to those able to write code for PC based >>> hardware. >>> >>> In order to open the SDR world to those with PC software skills we are >>> in >>> the process of developing a new SDR architecture. >>> >>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>> time and passes the 'raw' samples directly to an associated computer. >>> >>> This computer then calculates the FFT of the raw samples and >>> subsequently >>> processes the result as the user requires. >>> >>> This is not a totally new concept since both the cuSDR and KISS Konsole >>> software uses raw ADC samples to provide the wideband bandscope >>> displays. >>> >>> However, for this requirement the FFT only needs to be done at the >>> bandscope update rate of a few 10's of times per second, which hardly >>> taxes a modern PC at all. >>> >>> The new concept requires that we take the FFT of all samples in >>> real-time. >>> >>> This has been possible in the past - if you had access to a Cray super >>> computer! >>> >>> Well now we do have access to very low cost computers that provide the >>> processing power we need. One example of this is the new Nvidia Jetson >>> TK1 single board computer. At a cost of $192 this board contains four >>> ARM >>> CPUs plus 192 CUDA processors. >>> >>> More details of this remarkable board can be found here: >>> >>> https://developer.nvidia.com/jetson-tk1 >>> >>> Since the CUDA cores can process data in parallel, we can use these to >>> perform the high speed FFT. >>> >>> John, G0ORX, has written preliminary code for the Jetson board and has >>> confirmed that it has the necessary performance we require. >>> >>> The test environment consisted of a Jetson board connected via Gigabit >>> Ethernet to an Angelia board. A special version of FPGA code was >>> written >>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>> the >>> Jetson board. >>> >>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>> >>> Whilst it's still early days, and there is much more to be done, this >>> critical early success does indicate that this new architecture has a >>> very >>> promising future. >>> >>> The Jetson board is taking the role of an 'SDR Server' which I have >>> written about in the past. >>> >>> In which case what benefits does this new architecture provide to >>> openHPSR? >>> >>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>> and hence uses a small percentage of the space available with a >>> subsequent >>> reduction in power consumption. >>> >>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>> simplified since the SDR hardware only has to connect to a single, >>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>> required. The SDR Server simply needs to know the MAC address of the >>> SDR >>> hardware in order to communicate. It should be possible for a single >>> SDR >>> hardware board to feed multiple SDR Servers, but that's something for >>> the >>> future. >>> >>> 3. Virtually all the signal processing is undertaken on the associated >>> single board computer (SBC) or (suitable) PC. If sufficient processing >>> power is available then the GUI can run on the same SBC. Alternatively >>> the >>> user's normal PC (which does not require to be high performance since it >>> does not do any significant digital signal processing) or a Tablet, cell >>> phone etc could be used. >>> >>> 4. Many more users have the necessary skills and experience to support, >>> maintain and further develop the code. New features are added to the SDR >>> Server code rather than the FPGA code. >>> >>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>> FPGA >>> and/or power supply restrictions may have limited adding new features. >>> >>> 6. Future hardware upgrades will be to the associated SBC where faster >>> and >>> lower cost options can be expected. Nvidia have already indicated that >>> a >>> 64 bit board will be available in the near future. >>> >>> 7. Remote access to an SDR via the Internet will enable multiple users >>> to >>> share the SDR with each selecting their desired frequency, bandwidth and >>> mode. >>> >>> There are other potential benefits relating to simpler and lower cost >>> SDR >>> hardware, but that is for the future. >>> >>> For want of a name we are calling this new architecture 'Direct Fourier >>> Conversion' (DFC). >>> >>> For those that are already experimenting with the Jetson board we do >>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>> and >>> I will advise when, and where, this is available. >>> >>> John's code is presently not available, so please don't pester him, but >>> as >>> soon as it reaches Beta stage it will be released. >>> >>> Please join me in congratulating John on this exciting development. >>> >>> 73 Phil....VK6PH >>> >>> >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: >>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> >> > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From jeffrie at talktalk.net Wed Aug 20 06:25:58 2014 From: jeffrie at talktalk.net (Jeff Cook) Date: Wed, 20 Aug 2014 14:25:58 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <000001cfbc7a$47ce2d00$d76a8700$@talktalk.net> Hello Phil, As the epitome of what is an end user, button pusher, knob twiddler, et cetera, I readily admit to understanding little of which you speak, but your enthusiasm is infectious and your excitement palpable. I am still back in the days of Mercury and Ozymandias and love every minute of it, so thank you to you, and John, and all the others that are the true exponents of the radio art. It really is a pleasure being on board this particular magic of radio train, even though I have no idea where it's going. Jeff, G0AFQ. -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vrf at johnc57uk.plus.com Wed Aug 20 06:54:16 2014 From: g3vrf at johnc57uk.plus.com (G3VRF) Date: Wed, 20 Aug 2014 14:54:16 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <53F4A888.10302@johnc57uk.plus.com> Hi Phil et al, Having been around in Ham radio for a good long while now, I have seen many changes and advancements in the hobby over the many years but none as exciting as this. I would like to echo Jeff's sentiments G0AFQ, and express how sincerely grateful I am to yourself Phil, and all the others who have contributed to the HPSDR project and from whom I've benefited. I have a Hermes board and homebrew low power PA which works extremely well and is a pleasure to use. In my view it easily out performs my Yaesu and Icom transceivers on receive. When I complete the high power PA it will no doubt out perfom on tx as well. I have earwigged on the side for a long while now monitoring developments and comments with interest. Next step is to purchase a Jetson TK1 SBC and attempt to build cuSDR on that. Again my heartfelt thanks. 73s John G3VRF From chris at vspl.co.uk Wed Aug 20 07:12:21 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 15:12:21 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> References: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> Message-ID: <20140820141226.1ED8248937@diego.dreamhost.com> Hi Phil Not sure you meant J5 - that seems to be the I2C data bypass jumper. J9 HDR 5P TEST seems to have some interesting/useful I/O pins. Is that what you meant? 73 Chris G4NUX On 20 Aug 2014, at 12:37, Phil Harman wrote: > Hi Chris. > > Alternatively, you could make a small PCB that plugged into J5 on Mercury that held the PHY, 25MHz clock and Ethernet socket. Since you no longer need any DDC code in the FPGA you would have plenty of room to house the raw Ethernet code. > > 'Weekend Project' anyone ? > > 73 Phil....VK6PH > > > > > > -----Original Message----- From: Chris Smith > Sent: Wednesday, August 20, 2014 4:48 PM > To: phil at pharman.org > Cc: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > Hi Phil > > I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) > > Cheers > > Chris > > > On 20 Aug 2014, at 09:22, "Phil Harman" wrote: > >> Hi Chris, >> >> The limitation of using the Mercury board together with Metis is the >> bandwidth of the Alex bus. >> >> If would could couple the two boards together in a suitable way then we >> can use the existing Mercury board. >> >> 73 Phil...VK6PH >> >> >>> Hi Phil >>> >>> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >>> that DFC was the way things were going. Which is why I jumped on the TK1 >>> bandwagon. >>> >>> Will there ever be a way of using the Mercury front end to supply the raw >>> packets, perhaps with a bespoke daughter board? >>> >>> Congrats to John whom I had the pleasure of speaking to at Friedrischafen. >>> I'm sure we all look forward to the new era of SDR in the amateur radio >>> arena. >>> >>> Cheers & 73 >>> >>> Chris G4NUX >>> >>> On 20 Aug 2014, at 08:31, Phil Harman wrote: >>> >>>> ***** High Performance Software Defined Radio Discussion List ***** >>>> >>>> All, >>>> >>>> I'm delighted to be able to report that we have been able to develop, to >>>> proof-of-concept stage, a new SDR architecture. >>>> >>>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>>> DDC, >>>> in order to provide (multiple) receivers. Whist this is quite >>>> effective, >>>> much of the initial DSP work is done using FPGAs, or a combination of >>>> FPGA >>>> plus dedicated DSP chips and microprocessors, rather than totally within >>>> the PC. >>>> >>>> As more complex features are added, the size and complexity of the FPGA >>>> and DSP code increases. The skills to write, debug and maintain this >>>> code >>>> is only available via a small percentage of software engineers, or >>>> enthusiasts, in comparison to those able to write code for PC based >>>> hardware. >>>> >>>> In order to open the SDR world to those with PC software skills we are >>>> in >>>> the process of developing a new SDR architecture. >>>> >>>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>>> time and passes the 'raw' samples directly to an associated computer. >>>> >>>> This computer then calculates the FFT of the raw samples and >>>> subsequently >>>> processes the result as the user requires. >>>> >>>> This is not a totally new concept since both the cuSDR and KISS Konsole >>>> software uses raw ADC samples to provide the wideband bandscope >>>> displays. >>>> >>>> However, for this requirement the FFT only needs to be done at the >>>> bandscope update rate of a few 10's of times per second, which hardly >>>> taxes a modern PC at all. >>>> >>>> The new concept requires that we take the FFT of all samples in >>>> real-time. >>>> >>>> This has been possible in the past - if you had access to a Cray super >>>> computer! >>>> >>>> Well now we do have access to very low cost computers that provide the >>>> processing power we need. One example of this is the new Nvidia Jetson >>>> TK1 single board computer. At a cost of $192 this board contains four >>>> ARM >>>> CPUs plus 192 CUDA processors. >>>> >>>> More details of this remarkable board can be found here: >>>> >>>> https://developer.nvidia.com/jetson-tk1 >>>> >>>> Since the CUDA cores can process data in parallel, we can use these to >>>> perform the high speed FFT. >>>> >>>> John, G0ORX, has written preliminary code for the Jetson board and has >>>> confirmed that it has the necessary performance we require. >>>> >>>> The test environment consisted of a Jetson board connected via Gigabit >>>> Ethernet to an Angelia board. A special version of FPGA code was >>>> written >>>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>>> the >>>> Jetson board. >>>> >>>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>>> >>>> Whilst it's still early days, and there is much more to be done, this >>>> critical early success does indicate that this new architecture has a >>>> very >>>> promising future. >>>> >>>> The Jetson board is taking the role of an 'SDR Server' which I have >>>> written about in the past. >>>> >>>> In which case what benefits does this new architecture provide to >>>> openHPSR? >>>> >>>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>>> and hence uses a small percentage of the space available with a >>>> subsequent >>>> reduction in power consumption. >>>> >>>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>>> simplified since the SDR hardware only has to connect to a single, >>>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>>> required. The SDR Server simply needs to know the MAC address of the >>>> SDR >>>> hardware in order to communicate. It should be possible for a single >>>> SDR >>>> hardware board to feed multiple SDR Servers, but that's something for >>>> the >>>> future. >>>> >>>> 3. Virtually all the signal processing is undertaken on the associated >>>> single board computer (SBC) or (suitable) PC. If sufficient processing >>>> power is available then the GUI can run on the same SBC. Alternatively >>>> the >>>> user's normal PC (which does not require to be high performance since it >>>> does not do any significant digital signal processing) or a Tablet, cell >>>> phone etc could be used. >>>> >>>> 4. Many more users have the necessary skills and experience to support, >>>> maintain and further develop the code. New features are added to the SDR >>>> Server code rather than the FPGA code. >>>> >>>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>>> FPGA >>>> and/or power supply restrictions may have limited adding new features. >>>> >>>> 6. Future hardware upgrades will be to the associated SBC where faster >>>> and >>>> lower cost options can be expected. Nvidia have already indicated that >>>> a >>>> 64 bit board will be available in the near future. >>>> >>>> 7. Remote access to an SDR via the Internet will enable multiple users >>>> to >>>> share the SDR with each selecting their desired frequency, bandwidth and >>>> mode. >>>> >>>> There are other potential benefits relating to simpler and lower cost >>>> SDR >>>> hardware, but that is for the future. >>>> >>>> For want of a name we are calling this new architecture 'Direct Fourier >>>> Conversion' (DFC). >>>> >>>> For those that are already experimenting with the Jetson board we do >>>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>>> and >>>> I will advise when, and where, this is available. >>>> >>>> John's code is presently not available, so please don't pester him, but >>>> as >>>> soon as it reaches Beta stage it will be released. >>>> >>>> Please join me in congratulating John on this exciting development. >>>> >>>> 73 Phil....VK6PH >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> HPSDR Discussion List >>>> To post msg: hpsdr at openhpsdr.org >>>> Subscription help: >>>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>>> HPSDR web page: http://openhpsdr.org >>>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >>> >>> >>> >> > > > --- > This email is free from viruses and malware because avast! Antivirus protection is active. > http://www.avast.com From chris at vspl.co.uk Wed Aug 20 07:19:06 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 15:19:06 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <20140820141226.1ED8248937@diego.dreamhost.com> References: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> <20140820141226.1ED8248937@diego.dreamhost.com> Message-ID: <20140820141910.E5D7A489DF@diego.dreamhost.com> Whoops! No, I need to get some new glasses. J5 20-pin header has a whole bunch of good stuff on it. Sorry. 73 Chris G4NUX On 20 Aug 2014, at 15:12, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Phil > > Not sure you meant J5 - that seems to be the I2C data bypass jumper. J9 HDR 5P TEST seems to have some interesting/useful I/O pins. Is that what you meant? > > 73 Chris G4NUX > > On 20 Aug 2014, at 12:37, Phil Harman wrote: > >> Hi Chris. >> >> Alternatively, you could make a small PCB that plugged into J5 on Mercury that held the PHY, 25MHz clock and Ethernet socket. Since you no longer need any DDC code in the FPGA you would have plenty of room to house the raw Ethernet code. >> >> 'Weekend Project' anyone ? >> >> 73 Phil....VK6PH >> >> >> >> >> >> -----Original Message----- From: Chris Smith >> Sent: Wednesday, August 20, 2014 4:48 PM >> To: phil at pharman.org >> Cc: hpsdr at lists.openhpsdr.org >> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >> >> Hi Phil >> >> I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) >> >> Cheers >> >> Chris >> >> >> On 20 Aug 2014, at 09:22, "Phil Harman" wrote: >> >>> Hi Chris, >>> >>> The limitation of using the Mercury board together with Metis is the >>> bandwidth of the Alex bus. >>> >>> If would could couple the two boards together in a suitable way then we >>> can use the existing Mercury board. >>> >>> 73 Phil...VK6PH >>> >>> >>>> Hi Phil >>>> >>>> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >>>> that DFC was the way things were going. Which is why I jumped on the TK1 >>>> bandwagon. >>>> >>>> Will there ever be a way of using the Mercury front end to supply the raw >>>> packets, perhaps with a bespoke daughter board? >>>> >>>> Congrats to John whom I had the pleasure of speaking to at Friedrischafen. >>>> I'm sure we all look forward to the new era of SDR in the amateur radio >>>> arena. >>>> >>>> Cheers & 73 >>>> >>>> Chris G4NUX >>>> >>>> On 20 Aug 2014, at 08:31, Phil Harman wrote: >>>> >>>>> ***** High Performance Software Defined Radio Discussion List ***** >>>>> >>>>> All, >>>>> >>>>> I'm delighted to be able to report that we have been able to develop, to >>>>> proof-of-concept stage, a new SDR architecture. >>>>> >>>>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>>>> DDC, >>>>> in order to provide (multiple) receivers. Whist this is quite >>>>> effective, >>>>> much of the initial DSP work is done using FPGAs, or a combination of >>>>> FPGA >>>>> plus dedicated DSP chips and microprocessors, rather than totally within >>>>> the PC. >>>>> >>>>> As more complex features are added, the size and complexity of the FPGA >>>>> and DSP code increases. The skills to write, debug and maintain this >>>>> code >>>>> is only available via a small percentage of software engineers, or >>>>> enthusiasts, in comparison to those able to write code for PC based >>>>> hardware. >>>>> >>>>> In order to open the SDR world to those with PC software skills we are >>>>> in >>>>> the process of developing a new SDR architecture. >>>>> >>>>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>>>> time and passes the 'raw' samples directly to an associated computer. >>>>> >>>>> This computer then calculates the FFT of the raw samples and >>>>> subsequently >>>>> processes the result as the user requires. >>>>> >>>>> This is not a totally new concept since both the cuSDR and KISS Konsole >>>>> software uses raw ADC samples to provide the wideband bandscope >>>>> displays. >>>>> >>>>> However, for this requirement the FFT only needs to be done at the >>>>> bandscope update rate of a few 10's of times per second, which hardly >>>>> taxes a modern PC at all. >>>>> >>>>> The new concept requires that we take the FFT of all samples in >>>>> real-time. >>>>> >>>>> This has been possible in the past - if you had access to a Cray super >>>>> computer! >>>>> >>>>> Well now we do have access to very low cost computers that provide the >>>>> processing power we need. One example of this is the new Nvidia Jetson >>>>> TK1 single board computer. At a cost of $192 this board contains four >>>>> ARM >>>>> CPUs plus 192 CUDA processors. >>>>> >>>>> More details of this remarkable board can be found here: >>>>> >>>>> https://developer.nvidia.com/jetson-tk1 >>>>> >>>>> Since the CUDA cores can process data in parallel, we can use these to >>>>> perform the high speed FFT. >>>>> >>>>> John, G0ORX, has written preliminary code for the Jetson board and has >>>>> confirmed that it has the necessary performance we require. >>>>> >>>>> The test environment consisted of a Jetson board connected via Gigabit >>>>> Ethernet to an Angelia board. A special version of FPGA code was >>>>> written >>>>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>>>> the >>>>> Jetson board. >>>>> >>>>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>>>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>>>> >>>>> Whilst it's still early days, and there is much more to be done, this >>>>> critical early success does indicate that this new architecture has a >>>>> very >>>>> promising future. >>>>> >>>>> The Jetson board is taking the role of an 'SDR Server' which I have >>>>> written about in the past. >>>>> >>>>> In which case what benefits does this new architecture provide to >>>>> openHPSR? >>>>> >>>>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>>>> and hence uses a small percentage of the space available with a >>>>> subsequent >>>>> reduction in power consumption. >>>>> >>>>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>>>> simplified since the SDR hardware only has to connect to a single, >>>>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>>>> required. The SDR Server simply needs to know the MAC address of the >>>>> SDR >>>>> hardware in order to communicate. It should be possible for a single >>>>> SDR >>>>> hardware board to feed multiple SDR Servers, but that's something for >>>>> the >>>>> future. >>>>> >>>>> 3. Virtually all the signal processing is undertaken on the associated >>>>> single board computer (SBC) or (suitable) PC. If sufficient processing >>>>> power is available then the GUI can run on the same SBC. Alternatively >>>>> the >>>>> user's normal PC (which does not require to be high performance since it >>>>> does not do any significant digital signal processing) or a Tablet, cell >>>>> phone etc could be used. >>>>> >>>>> 4. Many more users have the necessary skills and experience to support, >>>>> maintain and further develop the code. New features are added to the SDR >>>>> Server code rather than the FPGA code. >>>>> >>>>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>>>> FPGA >>>>> and/or power supply restrictions may have limited adding new features. >>>>> >>>>> 6. Future hardware upgrades will be to the associated SBC where faster >>>>> and >>>>> lower cost options can be expected. Nvidia have already indicated that >>>>> a >>>>> 64 bit board will be available in the near future. >>>>> >>>>> 7. Remote access to an SDR via the Internet will enable multiple users >>>>> to >>>>> share the SDR with each selecting their desired frequency, bandwidth and >>>>> mode. >>>>> >>>>> There are other potential benefits relating to simpler and lower cost >>>>> SDR >>>>> hardware, but that is for the future. >>>>> >>>>> For want of a name we are calling this new architecture 'Direct Fourier >>>>> Conversion' (DFC). >>>>> >>>>> For those that are already experimenting with the Jetson board we do >>>>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>>>> and >>>>> I will advise when, and where, this is available. >>>>> >>>>> John's code is presently not available, so please don't pester him, but >>>>> as >>>>> soon as it reaches Beta stage it will be released. >>>>> >>>>> Please join me in congratulating John on this exciting development. >>>>> >>>>> 73 Phil....VK6PH >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> HPSDR Discussion List >>>>> To post msg: hpsdr at openhpsdr.org >>>>> Subscription help: >>>>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>>>> HPSDR web page: http://openhpsdr.org >>>>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >>>> >>>> >>>> >>> >> >> >> --- >> This email is free from viruses and malware because avast! Antivirus protection is active. >> http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From mark at buttery.org Wed Aug 20 07:20:53 2014 From: mark at buttery.org (=?UTF-8?B?U2hpcmxleSBNw6FycXVleiBEw7psY2V5?=) Date: Wed, 20 Aug 2014 10:20:53 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <000001cfbc53$85bf7be0$913e73a0$@de> References: <000001cfbc53$85bf7be0$913e73a0$@de> Message-ID: > Congratulations. Maybe a stupid question: Current bottleneck is the 1 Gbit/s > LAN connection that makes a decimation by factor 2 necessary or limits the > frequency range to 33MHz, i.e. we lose 6m band at least as raw I/Q. Is > there no (economic) way to get the LAN connection faster? 14 and 16 Bit > ADC/DACs are getting faster and low-jitter sampling oscillators up to 300MHz > are available, hence a lot of nice applications are imaginable, hi. With the current boards there may not be. But a variety of standardized higher speed interfaces are available, including eSATA, Thunderbolt, USB 3.0, and 10G Ethernet. A future design could move to one of those. From meijer.ha at home.nl Wed Aug 20 08:29:00 2014 From: meijer.ha at home.nl (H.A.Meijer) Date: Wed, 20 Aug 2014 17:29:00 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> References: <53F46332.9040601@home.nl> <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> Message-ID: <53F4BEBC.9080105@home.nl> Hi Phil, So, just to simplify, so that I also understand, this Jetson board could replace (more or less) the on-board FPGA, being more powerful(?) and easier to code for the more 'average' software engineer?. And the (high performance) (W)DSP software, that's now running on or PC's, can easily by done by that board? and not just some very basic DSP work, I see at some 'other' popular sdr transceiver. The only problem I see for now is that there will be an extra 'data highway', between the sdr hardware and the end-user interface PC, that could coarse extra problems/latency..etc.. We will see what the future brings. Thanks, 73 Bert PA2XHF Phil Harman schreef op 20-8-2014 om 13:15: > Hi Bert, > Yes, as we are today the ?new board? is connected between your SDR > hardware and your PC. > It may be possible to run both the SDR server and Client GUI software > on the one SBC or PC. Its a little early yet to know if the Jetson > board is capable of doing this. > If so, then with your SDR hardware you would have a dedicated SDR that > does not require an additional PC. This could all be packaged into a > case with a suitable touch screen etc. > You can always do that today by using a suitable SBC that will run > Windows. > 73 Phil...VK6PH > > > > ------------------------------------------------------------------------ > --- Dit e-mailbericht bevat geen virussen en malware omdat avast! Antivirus-bescherming actief is. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dc6ny at gmx.de Wed Aug 20 10:55:20 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Wed, 20 Aug 2014 19:55:20 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <000001cfbc53$85bf7be0$913e73a0$@de> Message-ID: <000001cfbc9f$e8de2bd0$ba9a8370$@de> Thanks for reply, Mark. 73, Helmut -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von Shirley M?rquez D?lcey Gesendet: Mittwoch, 20. August 2014 16:21 An: hpsdr at lists.openhpsdr.org Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** > Congratulations. Maybe a stupid question: Current bottleneck is the 1 > Gbit/s LAN connection that makes a decimation by factor 2 necessary or > limits the frequency range to 33MHz, i.e. we lose 6m band at least as > raw I/Q. Is there no (economic) way to get the LAN connection faster? > 14 and 16 Bit ADC/DACs are getting faster and low-jitter sampling > oscillators up to 300MHz are available, hence a lot of nice applications are imaginable, hi. With the current boards there may not be. But a variety of standardized higher speed interfaces are available, including eSATA, Thunderbolt, USB 3.0, and 10G Ethernet. A future design could move to one of those. _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From doug at dougronald.com Wed Aug 20 11:22:33 2014 From: doug at dougronald.com (Doug Ronald) Date: Wed, 20 Aug 2014 11:22:33 -0700 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <007a01cfbca3$b7bfb880$273f2980$@dougronald.com> Hi, Could you give some idea of what is the present capability with regard to FFT's per second, and the bin size? I mean extracting from the information bandwidth for communications purposes, not simply for the frequency domain display. I'm curious to know if this would allow one to FFT over a 30 MHz bandwidth to say a 500 Hz bandwidth or even a 2.4 kHz bandwidth. That would be extremely useful. Thanks, -Doug Ronald AE6SY -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Phil Harman Sent: Wednesday, August 20, 2014 12:31 AM To: hpsdr at lists.openhpsdr.org Subject: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. In order to open the SDR world to those with PC software skills we are in the process of developing a new SDR architecture. This architecture digitises the entire 0 to 30MHz radio spectrum in real time and passes the 'raw' samples directly to an associated computer. This computer then calculates the FFT of the raw samples and subsequently processes the result as the user requires. This is not a totally new concept since both the cuSDR and KISS Konsole software uses raw ADC samples to provide the wideband bandscope displays. However, for this requirement the FFT only needs to be done at the bandscope update rate of a few 10's of times per second, which hardly taxes a modern PC at all. The new concept requires that we take the FFT of all samples in real-time. This has been possible in the past - if you had access to a Cray super computer! Well now we do have access to very low cost computers that provide the processing power we need. One example of this is the new Nvidia Jetson TK1 single board computer. At a cost of $192 this board contains four ARM CPUs plus 192 CUDA processors. More details of this remarkable board can be found here: https://developer.nvidia.com/jetson-tk1 Since the CUDA cores can process data in parallel, we can use these to perform the high speed FFT. John, G0ORX, has written preliminary code for the Jetson board and has confirmed that it has the necessary performance we require. The test environment consisted of a Jetson board connected via Gigabit Ethernet to an Angelia board. A special version of FPGA code was written for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the Jetson board. We used raw Ethernet frames over the Gigabit link, in order to maximise the link bandwidth, since we require a sustained 983Mbps transfer rate. Whilst it's still early days, and there is much more to be done, this critical early success does indicate that this new architecture has a very promising future. The Jetson board is taking the role of an 'SDR Server' which I have written about in the past. In which case what benefits does this new architecture provide to openHPSR? 1. The FPGA code is greatly simplified, is easier to write and maintain, and hence uses a small percentage of the space available with a subsequent reduction in power consumption. 2. The protocol between the SDR hardware and the SDR Server is greatly simplified since the SDR hardware only has to connect to a single, dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer required. The SDR Server simply needs to know the MAC address of the SDR hardware in order to communicate. It should be possible for a single SDR hardware board to feed multiple SDR Servers, but that's something for the future. 3. Virtually all the signal processing is undertaken on the associated single board computer (SBC) or (suitable) PC. If sufficient processing power is available then the GUI can run on the same SBC. Alternatively the user's normal PC (which does not require to be high performance since it does not do any significant digital signal processing) or a Tablet, cell phone etc could be used. 4. Many more users have the necessary skills and experience to support, maintain and further develop the code. New features are added to the SDR Server code rather than the FPGA code. 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA and/or power supply restrictions may have limited adding new features. 6. Future hardware upgrades will be to the associated SBC where faster and lower cost options can be expected. Nvidia have already indicated that a 64 bit board will be available in the near future. 7. Remote access to an SDR via the Internet will enable multiple users to share the SDR with each selecting their desired frequency, bandwidth and mode. There are other potential benefits relating to simpler and lower cost SDR hardware, but that is for the future. For want of a name we are calling this new architecture 'Direct Fourier Conversion' (DFC). For those that are already experimenting with the Jetson board we do intend to release the DFC FPGA code for both Angelia and Hermes boards and I will advise when, and where, this is available. John's code is presently not available, so please don't pester him, but as soon as it reaches Beta stage it will be released. Please join me in congratulating John on this exciting development. 73 Phil....VK6PH _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From jm-hpsdr at themarvins.org Wed Aug 20 12:57:07 2014 From: jm-hpsdr at themarvins.org (John Marvin) Date: Wed, 20 Aug 2014 13:57:07 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F4FD93.900@themarvins.org> I see no mention of the transmit side. I assume the current prototype (FPGA in particular) is a receive only implementation? Is DUC still the planned approach for transmit? I may get my 12 receivers (simultanous WSPR reception on all current and experimental ham bands 10m and below) on Hermes yet! Thanks for the update, John AC0ZG On 8/20/2014 1:31 AM, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From douglas.adams at me.com Wed Aug 20 17:11:51 2014 From: douglas.adams at me.com (Doug Adams) Date: Wed, 20 Aug 2014 20:11:51 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: Phil, This all sounds great, I'm all for advancing the "state-of-the-art". It would be great if an option was to have the SBC on a PCIE bus, that way it could be placed directly into a computer with such an interface (most PC's) or put into a PCIE Expansion box (e.g. a Mac expansion box fed by a Thunderbolt cable). That would get us a very high speed connection to the device and some OS independence. Does this also mean that the proposed changes to the Metis / Hermes protocol from the "Discussion Paper - openHPSDR Ethernet Protocol" are not going to be done? 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at pharman.org Wed Aug 20 17:24:01 2014 From: phil at pharman.org (Phil Harman) Date: Thu, 21 Aug 2014 08:24:01 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F4FD93.900@themarvins.org> References: <53F4FD93.900@themarvins.org> Message-ID: <6226ab1d7b126fbb9ea9a51ba1e90654.squirrel@webmail.eftel.com.au> Hi John, Doing a similar approach for the transmitter is something for the future. If you only want 12 receivers then we can reduce it to that number :) 73 Phil... > ***** High Performance Software Defined Radio Discussion List ***** > > I see no mention of the transmit side. I assume the current prototype > (FPGA in particular) is a receive only implementation? Is DUC still the > planned approach for transmit? > > I may get my 12 receivers (simultanous WSPR reception on all current and > experimental ham bands 10m and below) on Hermes yet! > > Thanks for the update, > > John > AC0ZG > > On 8/20/2014 1:31 AM, Phil Harman wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> I'm delighted to be able to report that we have been able to develop, to >> proof-of-concept stage, a new SDR architecture. >> >> Current SDRs use the software equivalent of zero IF techniques, i.e. >> DDC, >> in order to provide (multiple) receivers. Whist this is quite >> effective, >> much of the initial DSP work is done using FPGAs, or a combination of >> FPGA >> plus dedicated DSP chips and microprocessors, rather than totally within >> the PC. >> >> As more complex features are added, the size and complexity of the FPGA >> and DSP code increases. The skills to write, debug and maintain this >> code >> is only available via a small percentage of software engineers, or >> enthusiasts, in comparison to those able to write code for PC based >> hardware. >> >> In order to open the SDR world to those with PC software skills we are >> in >> the process of developing a new SDR architecture. >> >> This architecture digitises the entire 0 to 30MHz radio spectrum in real >> time and passes the 'raw' samples directly to an associated computer. >> >> This computer then calculates the FFT of the raw samples and >> subsequently >> processes the result as the user requires. >> >> This is not a totally new concept since both the cuSDR and KISS Konsole >> software uses raw ADC samples to provide the wideband bandscope >> displays. >> >> However, for this requirement the FFT only needs to be done at the >> bandscope update rate of a few 10's of times per second, which hardly >> taxes a modern PC at all. >> >> The new concept requires that we take the FFT of all samples in >> real-time. >> >> This has been possible in the past - if you had access to a Cray super >> computer! >> >> Well now we do have access to very low cost computers that provide the >> processing power we need. One example of this is the new Nvidia Jetson >> TK1 single board computer. At a cost of $192 this board contains four >> ARM >> CPUs plus 192 CUDA processors. >> >> More details of this remarkable board can be found here: >> >> https://developer.nvidia.com/jetson-tk1 >> >> Since the CUDA cores can process data in parallel, we can use these to >> perform the high speed FFT. >> >> John, G0ORX, has written preliminary code for the Jetson board and has >> confirmed that it has the necessary performance we require. >> >> The test environment consisted of a Jetson board connected via Gigabit >> Ethernet to an Angelia board. A special version of FPGA code was >> written >> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >> the >> Jetson board. >> >> We used raw Ethernet frames over the Gigabit link, in order to maximise >> the link bandwidth, since we require a sustained 983Mbps transfer rate. >> >> Whilst it's still early days, and there is much more to be done, this >> critical early success does indicate that this new architecture has a >> very >> promising future. >> >> The Jetson board is taking the role of an 'SDR Server' which I have >> written about in the past. >> >> In which case what benefits does this new architecture provide to >> openHPSR? >> >> 1. The FPGA code is greatly simplified, is easier to write and maintain, >> and hence uses a small percentage of the space available with a >> subsequent >> reduction in power consumption. >> >> 2. The protocol between the SDR hardware and the SDR Server is greatly >> simplified since the SDR hardware only has to connect to a single, >> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >> required. The SDR Server simply needs to know the MAC address of the >> SDR >> hardware in order to communicate. It should be possible for a single >> SDR >> hardware board to feed multiple SDR Servers, but that's something for >> the >> future. >> >> 3. Virtually all the signal processing is undertaken on the associated >> single board computer (SBC) or (suitable) PC. If sufficient processing >> power is available then the GUI can run on the same SBC. Alternatively >> the >> user's normal PC (which does not require to be high performance since it >> does not do any significant digital signal processing) or a Tablet, cell >> phone etc could be used. >> >> 4. Many more users have the necessary skills and experience to support, >> maintain and further develop the code. New features are added to the SDR >> Server code rather than the FPGA code. >> >> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >> FPGA >> and/or power supply restrictions may have limited adding new features. >> >> 6. Future hardware upgrades will be to the associated SBC where faster >> and >> lower cost options can be expected. Nvidia have already indicated that >> a >> 64 bit board will be available in the near future. >> >> 7. Remote access to an SDR via the Internet will enable multiple users >> to >> share the SDR with each selecting their desired frequency, bandwidth and >> mode. >> >> There are other potential benefits relating to simpler and lower cost >> SDR >> hardware, but that is for the future. >> >> For want of a name we are calling this new architecture 'Direct Fourier >> Conversion' (DFC). >> >> For those that are already experimenting with the Jetson board we do >> intend to release the DFC FPGA code for both Angelia and Hermes boards >> and >> I will advise when, and where, this is available. >> >> John's code is presently not available, so please don't pester him, but >> as >> soon as it reaches Beta stage it will be released. >> >> Please join me in congratulating John on this exciting development. >> >> 73 Phil....VK6PH >> >> >> >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > From wb4gcs at wb4gcs.org Wed Aug 20 17:37:23 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Wed, 20 Aug 2014 20:37:23 -0400 Subject: [hpsdr] Interesting email on SDR transmit noise In-Reply-To: <5261FFA0.8080001@tx.rr.com> References: <5261FFA0.8080001@tx.rr.com> Message-ID: <53F53F43.5010205@wb4gcs.org> WOW! Has anybody made similar measurements on Penny/Munim?? 73, Jim wb4gcs at amsat.org On 10/18/2013 11:42 PM, KA5FPT Paul wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I saw the following on the Flexradio mail list. I am having some > problems understanding how a SDR transmitter can cause wide band > noise. I would have thought that with proper filtering it would be > controlled. > ----------------------------------------------------------------------------------------------- > > > Date: Wed, 16 Oct 2013 14:59:37 -0400 > From: "Gedas" > To: > Subject: [Flexradio] Noise Sidebands, Article by SM5BSZ > Message-ID: <399ADD464530473F88C1CBF0659768F5 at biggy> > Content-Type: text/plain; charset="utf-8" > > I came across this interesting article by SM5BSZ who discusses some > possible transmitter issues with many radios, including the Flex. It > has me a bit concerned. I am wondering if anyone has seen similar > data for the Flex 5000? The article may be found here: > > http://www.sm5bsz.com/dynrange/dubus313.pdf > > Gedas, W8BYA > Gallery athttp://w8bya.com > Light travels faster than sound.... > This is why some people appear bright until you hear them speak. > > -------------------------------------------------------------------------------------------------- > > > 73, > Paul Cecil > KA5FPT > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From phil at pharman.org Wed Aug 20 17:53:29 2014 From: phil at pharman.org (Phil Harman) Date: Thu, 21 Aug 2014 08:53:29 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F4BEBC.9080105@home.nl> References: <53F46332.9040601@home.nl> <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> <53F4BEBC.9080105@home.nl> Message-ID: Hi Bert, > So, just to simplify, so that I also understand, this Jetson board > could replace (more or less) the on-board FPGA, > being more powerful(?) and easier to code for the more 'average' > software engineer?. Yes, it does replace a large percentage of the FPGA code, not so sure about more powerful, but many more enthusiasts will be able to contribute. If there is enough spare capacity, or a future board has, then it could also replace the PC. > And the (high performance) (W)DSP software, that's now running on or > PC's, can easily by done by that board? > and not just some very basic DSP work, I see at some 'other' popular sdr > transceiver. Yes. > The only problem I see for now is that there will be an extra 'data > highway', between the sdr hardware > and the end-user interface PC, that could coarse extra > problems/latency..etc.. The data between the SDR Server and PC will only be low bandwidth. The Audio and bandscope data can be compressed so that we are perhaps only looking at 200kbps or even less. For digital modes it may be necessary to send I&Q data to the PC which will increase the bandwidth required. > We will see what the future brings. Yes, early days for DFC yet. We still have a lot to learn! 73 Phil...VK6PH From jm-hpsdr at themarvins.org Wed Aug 20 20:35:16 2014 From: jm-hpsdr at themarvins.org (John Marvin) Date: Wed, 20 Aug 2014 21:35:16 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <6226ab1d7b126fbb9ea9a51ba1e90654.squirrel@webmail.eftel.com.au> References: <53F4FD93.900@themarvins.org> <6226ab1d7b126fbb9ea9a51ba1e90654.squirrel@webmail.eftel.com.au> Message-ID: <53F568F4.3070204@themarvins.org> Oh, I'm quite aware that with this architecture the number of receivers is purely limited by the processing power and bandwidth you can apply to the problem. I look forward to playing with a fpga supporting this for Hermes. With this architecture it might make more sense for many use cases to do the I/O on the SBC (i.e. mike/line in and headphone/speaker out), but I hope that you will also preserve the capability of using the onboard Hermes I/O, i.e. still provide a synchronous mike stream with the single ultra wide data receive stream, and a synchronous speaker headphone channel, along with the control necessary to support them. Thanks, John On 8/20/2014 6:24 PM, Phil Harman wrote: > Hi John, > > Doing a similar approach for the transmitter is something for the future. > > If you only want 12 receivers then we can reduce it to that number :) > > 73 Phil... > > > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> I see no mention of the transmit side. I assume the current prototype >> (FPGA in particular) is a receive only implementation? Is DUC still the >> planned approach for transmit? >> >> I may get my 12 receivers (simultanous WSPR reception on all current and >> experimental ham bands 10m and below) on Hermes yet! >> >> Thanks for the update, >> >> John >> AC0ZG >> >> From lstoskopf at cox.net Thu Aug 21 07:55:49 2014 From: lstoskopf at cox.net (lstoskopf at cox.net) Date: Thu, 21 Aug 2014 10:55:49 -0400 Subject: [hpsdr] HackRF tutorial Message-ID: <20140821105549.YWEKY.153771.imail@eastrmwml106> Perhaps of interest: http://greatscottgadgets.com/sdr N0UU From peroy at broadpark.no Thu Aug 21 12:05:42 2014 From: peroy at broadpark.no (=?iso-8859-1?Q?=22Per_=D8yvind_Jonsson=22?=) Date: Thu, 21 Aug 2014 21:05:42 +0200 Subject: [hpsdr] Common Hermes firmware for Anan/Alex/Apollo? Message-ID: <77c0b3bd26a74.53f65f26@broadpark.no> First, thank you to the gurus for the fantastic effort with hardware, firmware and software! There is however one Hermes issue which begs to be solved, both to reduce user confusion, and hopefully also the effort needed to update the firmware. Today we need two Hermes FW versions. My understanding is that this is because the ANAN-10 and ALEX filters have different cut-off frequencies. It would of course be nice if Hermes could auto-detect which filter board is connected, but based on the schematics I have seen this will require some hardware modifications. Possible, but not desirable. When setting up PowerSDR we already need to specify the radio model, and some of this information is sent to Hermes. Would it be possible to extend this to also send information on which filter board is used? This could allow the FW to set the proper filter parameters. According to the USB_protocol_V1.58 there does not seem to be any bits that could be used directly, but it may be possible to use some otherwise unused combinations. One possibility seems to be to use C2 in the sequence starting with C0 = 0001001x, like this: bit 7: VNA mode (no change) bit 6: Alex manual (no change) bit 5: Hermes filter board (0 = Alex or ANAN, 1 = Apollo) bit 4-3-2: If bit 5 = 1 sets Apollo options (no change) If bit 5 = 0 could be used to specify which board(s) like so: 000 - None 001 - Alex RX 010 - Alex TX 011 - Alex RX+TX 100 - ANAN-10 other combinations available for future boards? bit 1: Metis/Penelope etc Mic/Line In (no change) bit 0: Hermes etc Mic Boost (no change) Thoughts/comments? LA9WX -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at foxgulch.com Fri Aug 22 09:41:09 2014 From: larry at foxgulch.com (Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop) Date: Fri, 22 Aug 2014 10:41:09 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> Message-ID: <53F772A5.9050001@foxgulch.com> Attempted to upgrade the firmware in my 100D using HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when I attempted to write 4.1 rbf, all operations stopped. Now it won't boot. (J17 jumper on or off, doesn't help) So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and fired off the Altera Quartus Programmer v12 build 177 11/7/2012 which responded after I clicked Start as follows: Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 2014 Info (209018): Device 1 silicon ID is 0x18 Info (209044): Erasing ASP configuration device(s) Info (209024): Programming device 1 Info (209018): Device 1 silicon ID is 0x18 Info (209011): Successfully performed operation(s) Info (209061): Ended Programmer operation at Fri Aug 22 15:26:15 2014 which looked OK but no boot! Second from left front panel red led glows constantly but dim. Somewhere I noticed (post by Franz Hegener) that I should have selected EPC 128? My device (in the Quartus II 32 bit Programmer window shows Device=EPCS16 as read from Quartus-II Programmer window and also shown in the document "Quartus-II Programmer and Byteblaster" by N9VV and KCXG v2.3 dated 04/23/13. Is this my error? Any ideas to try next?? Thanks, Larry W0AY Note for record: 1. Version 12 of the Quartus II Programmer matches the "Quartus-II Programmer and Byteblaster" instructions (noted above) but the current version V12 does not. Obtain V12 here: https://www.altera.com/download/sw/dnl-sw-index.jsp# 2. Win7 refused to load the drivers provided by Altera in V14. I used the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 From k5so at valornet.com Fri Aug 22 10:20:32 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Fri, 22 Aug 2014 11:20:32 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: <53F772A5.9050001@foxgulch.com> References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: Hi Larry, Sorry to hear you?re having trouble programming your 100D. I suspect that when you first had your problem you could?ve recovered by using Bootloader mode, but perhaps something went awry. No problem, it?s all recoverable no matter what you did. Sounds like you have the Quartus II Programmer and your blaster cable talking fine to each other so you needn?t worry about trying to load v14 Quartus from Altera (in fact, I recommend not using v14). Here I use Quartus II v13.0 for most of my work but the Quartus II Programmer in v12 or likely any other earlier version will work to program an EEPROM config device so I wouldn?t worry about finding a particular version of Quartus II Programmer; it?s not that critical which you use, generally (at least in my experience). The Angelia board uses an EPCS128 EEPROM configuration device (not an EPCS16) so that is the device you should specify in the Quartus II Programmer. You should be plugging your blaster cable onto P2 and loading the file ?output_file.pof? for Angelia. The ?output_file.pof? contains both the bootloader code and the binary FPGA image that gets loaded later into the FPGA. If you erroneously load ?Angelia.pof? you will not be loading the bootloader code into the EEPROM with the FPGA image, you?ll only be loading the FPGA image. It will run and come up on power up but there is not bootloader code in it so should you later wish to use ?Bootloader? mode you cannot. Use the ?output_file.pof? to load into the EEPROM and you?ll be good. 73, Joe K5SO On Aug 22, 2014, at 10:41 AM, Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Attempted to upgrade the firmware in my 100D using HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when I attempted to write 4.1 rbf, all operations stopped. Now it won't boot. (J17 jumper on or off, doesn't help) > > So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and fired off the Altera Quartus Programmer v12 build 177 11/7/2012 which responded after I clicked Start as follows: > > Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 2014 > Info (209018): Device 1 silicon ID is 0x18 > Info (209044): Erasing ASP configuration device(s) > Info (209024): Programming device 1 > Info (209018): Device 1 silicon ID is 0x18 > Info (209011): Successfully performed operation(s) > Info (209061): Ended Programmer operation at Fri Aug 22 15:26:15 2014 > > which looked OK but no boot! Second from left front panel red led glows constantly but dim. > > Somewhere I noticed (post by Franz Hegener) that I should have selected EPC 128? My device (in the Quartus II 32 bit Programmer window shows Device=EPCS16 as read from Quartus-II Programmer window and also shown in the document "Quartus-II Programmer and Byteblaster" by N9VV and KCXG v2.3 dated 04/23/13. Is this my error? > > Any ideas to try next?? > > Thanks, > Larry W0AY > > Note for record: > 1. Version 12 of the Quartus II Programmer matches the "Quartus-II Programmer and Byteblaster" instructions (noted above) but the current version V12 does not. Obtain V12 here: https://www.altera.com/download/sw/dnl-sw-index.jsp# > > 2. Win7 refused to load the drivers provided by Altera in V14. I used the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From k5so at valornet.com Fri Aug 22 10:34:54 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Fri, 22 Aug 2014 11:34:54 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: <6CDCF9A3-A76E-4203-8939-984BA727DED3@valornet.com> Larry, One further comment, when loading an ?output_file.pof? into your Angelia it will power up with whatever firmware version number was used when the ?output_file.pof? was created. Therefore, after recovering using the blaster cable you will still need to update the firmware version to v4.1. If v4.1 happened to be used in creating the ?output_file.pof? then you do not need to update to v4.1 as it will already be loaded as part of the ?output_file.pof?. If you?re reluctant to try the update the Angelia using the HPSDRProgrammer the I?d suggest using the HPSDR Bootloader program instead, as it seems to be more robust (using a jumper on J17 during the update operation with HPSDR Bootloader, of course). The program you?d load using the HPSDR Bootloader is the same as you?d use with the HPSDR Programmer; namely, ?Angelia_v4.1.rbf?. 73, Joe K5SO From w5wc at windstream.net Fri Aug 22 10:43:04 2014 From: w5wc at windstream.net (Doug Wigley) Date: Fri, 22 Aug 2014 12:43:04 -0500 Subject: [hpsdr] PowerSDR/OpenHPSDR mRX PS v3.2.18 released Message-ID: <005601cfbe30$877604c0$96620e40$@net> All, PowerSDR/OpenHPSDR mRX PS v3.2.18 has been released. This is primarly a maintenace release which has a few bug fixes and feature enhancements added. The noteworthy changes are: - PowerSDR will check the database version being used on startup. If the databse was written by an older version of PowerSDR you will receive a warning and a choice to reset the database at that time. - Diversity values for the Reference Source, Gain, and Phase are saved and restored by band. - Diversity can now be enabled/disabled with the Diversity Form opened. - The PTT Control port can now use the same port as the CAT Control. This release can be downloaded from the openhpsdr.org website. http://openhpsdr.org/download.php 73, Doug W5WC From jkelly at verizon.net Fri Aug 22 13:12:28 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 22 Aug 2014 16:12:28 -0400 Subject: [hpsdr] FS - Band-pass filter Message-ID: Assembled Band-pass filter (BPF for SDR HERMES, ANAN-10 or HF transceiver) Similar to: http://www.ebay.com/itm/Band-pass-filter-BPF-for-SDR-HERMES-ANAN-10-or-HF-transceiver-/251578249143? $175. shipped CONUS. Jeff K2SDR -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkelly at verizon.net Fri Aug 22 14:22:37 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 22 Aug 2014 17:22:37 -0400 Subject: [hpsdr] FS - Band-pass filter In-Reply-To: References: Message-ID: <70FA5EC3B6604DCDB8E4102C084BD771@JeffPC> SOLD. Jeff From: Jeff Kelly Sent: Friday, August 22, 2014 16:12 To: hpsdr at openhpsdr.org Subject: [hpsdr] FS - Band-pass filter ***** High Performance Software Defined Radio Discussion List ***** -------------------------------------------------------------------------------- Assembled Band-pass filter (BPF for SDR HERMES, ANAN-10 or HF transceiver) Similar to: http://www.ebay.com/itm/Band-pass-filter-BPF-for-SDR-HERMES-ANAN-10-or-HF-transceiver-/251578249143? $175. shipped CONUS. Jeff K2SDR -------------------------------------------------------------------------------- _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From leskep at skymesh.com.au Fri Aug 22 16:12:40 2014 From: leskep at skymesh.com.au (Les Keppie) Date: Sat, 23 Aug 2014 09:12:40 +1000 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: <53F772A5.9050001@foxgulch.com> References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: Hi All I have experienced a similar situation regarding v4.1 whilst trying to revert to v4.0 After upgrading to v4.1 when it became available I only had it running for a short period when I was experiencing distorted audio - checked all bands same result - decided to revert to v4.0 firmware Using Programmer old file was reported as deleted but no perecntage values appeared when uploading the new file and the process never did complete I then switched to the Bootloader and again tried load v4.0 firmware - same result as using the Programmer This happened the day before I was due to go on 2 weeks holiday so just left everything as was On returning I thought about it for a while and decided to try the Bootloader and was able to upgrade to v4.1 and no distorted audio problems - have been running it now for some 4 days without any problems Just thought I would put this out for information Regards Les VK2DSG On Sat, 23 Aug 2014 02:41:09 +1000, Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Attempted to upgrade the firmware in my 100D using > HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when > I attempted to write 4.1 rbf, all operations stopped. Now it won't > boot. (J17 jumper on or off, doesn't help) > > So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and fired > off the Altera Quartus Programmer v12 build 177 11/7/2012 which > responded after I clicked Start as follows: > > Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 2014 > Info (209018): Device 1 silicon ID is 0x18 > Info (209044): Erasing ASP configuration device(s) > Info (209024): Programming device 1 > Info (209018): Device 1 silicon ID is 0x18 > Info (209011): Successfully performed operation(s) > Info (209061): Ended Programmer operation at Fri Aug 22 15:26:15 2014 > > which looked OK but no boot! Second from left front panel red led > glows constantly but dim. > > Somewhere I noticed (post by Franz Hegener) that I should have > selected EPC 128? My device (in the Quartus II 32 bit Programmer > window shows Device=EPCS16 as read from Quartus-II Programmer window and > also shown in the document "Quartus-II Programmer and Byteblaster" by > N9VV and KCXG v2.3 dated 04/23/13. Is this my error? > > Any ideas to try next?? > > Thanks, > Larry W0AY > > Note for record: > 1. Version 12 of the Quartus II Programmer matches the "Quartus-II > Programmer and Byteblaster" instructions (noted above) but the current > version V12 does not. Obtain V12 here: > https://www.altera.com/download/sw/dnl-sw-index.jsp# > > 2. Win7 refused to load the drivers provided by Altera in V14. I used > the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Using Opera's mail client: http://www.opera.com/mail/ From k5so at valornet.com Fri Aug 22 18:07:18 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Fri, 22 Aug 2014 19:07:18 -0600 Subject: [hpsdr] Angelia_v4.2 firmware release Message-ID: All, Angelia_v4.2 firmware is available for download from http://k5so.com/HPSDR_downloads.html This version of firmware slightly modifies the timing of v4.1 to make the design more robust with respect to running on many different Angelia boards. A few people have reported problems with v4.1 where one or more features became inoperable after 30 minutes or so of operation (e.g., CW sidetone simply stopping, etc). Most Angelia boards had no problem with v4.1 apparently but a few did. This v4.2 appears to have fixed those problems and appears to work fine on other Angelia boards too. I don?t know if the recently reported trouble experienced by a few people using HPSDR Programmer to update firmware in Angelia will be helped by this new firmware but it could, perhaps. In any case, should you run into trouble using HPSDR Programmer in the normal manner you should be able to use the HPSDR Bootloader program to recover. For those who wish to use the "brute force" method of completely reloading the Angelia EEPROM (including the bootloader code) by using a blaster cable with the Quartus II Programmer, I have created a new ?output_file.pof? file that includes both Angelia_v4.2 image and the bootloader code in it and I have included it in the zipped Angelia_v4.2 download folder. Using this ?output_file.pof? file will relieve you of the task of updating to v4.2 after loading the bootloader code, which you would need to do if you use an earlier version of ?output_file.pof? in your blaster cable process. Please keep in mind that you should not need to use a blaster cable to recover from a failed attempt to update firmware using HPSDR Programmer; recovery using HPSDR Bootloader (with J17 jumper in place, of course) should work for you in those (hopefully relatively rare!) cases. I included this new ?output_file.pof" file in the download folder only as a ?peace of mind? item and courtesy for those who like to use their blaster cables, hihi. 73, Joe K5SO From mlalonde at alphatronique.com Fri Aug 22 19:31:43 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Fri, 22 Aug 2014 22:31:43 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F7FD0F.6020301@alphatronique.com> Hi guess some one already work on a ADC /DAC Board that go on the expansion connector of the DEV kit ? seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA as Glue logic.. that may remove the LAN / PHY from equation and permit made nice self contained platform ;-) if no one yet ,i may willing to help work on this ,i was a senior PCB designer whit some design backgrond .. Best 73! Marc VE2OLM On 20/08/2014 3:31 AM, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From aa8k73 at gmail.com Fri Aug 22 19:43:52 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 22 Aug 2014 22:43:52 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/23 Message-ID: <53F7FFE8.3030108@gmail.com> The 23/Aug TeamSpeak mp3 (63 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3512 > or < http://www.hamsdr.com/dnld.aspx > Only silence truncation editing was done on this recording. Session text follows <20:35:08> *** You are now talking in channel: "OpenHPSDR" <21:06:29> "Bill - KD5TFD": needs better networking? <21:08:21> "Bill - KD5TFD": If he's an expert it's only an afternoon project <21:13:48> "Ken N9VV": CWSkimmer <21:18:15> "Warren - NR0V": < https://dl.dropboxusercontent.com/u/9282924/hpsdr/xcmaster.JPG > <21:28:04> "Ken N9VV": "Bonding" <21:28:32> "Bill - KD5TFD": 2 lane highway <21:28:56> "Jae - K5JAE": pci-e? <21:31:32> "Bill - KD5TFD": You mean I can't do 30 Mhz wide transmit? <21:32:20> "Bill - KD5TFD": light weight gui .. now that's an oxymoron <21:33:26> "Ken N9VV": Lightweight GUI = Android glSDR or HPSDR with Qt server doing all the work(?) <21:36:02> "Jae - K5JAE": FreeDV? <21:46:03> "Ken N9VV": K5SO released Angelia 4.2 tonight --- < http://k5so.com/Angelia_v4.2.zip > <21:47:46> "Bill - KD5TFD": anyone have a vnc server running on their Jetson? <21:51:50> "Jae - K5JAE": software is soft... hardware is hard :) <21:52:45> "Ken N9VV": SDRMAX = circa: 2004 according to N8VB Blog <21:55:56> "Rob - VE3EW": < http://www.iwavesystems.com/product/cpu-modules/cyclone-v-soc-qseven-som/altera-cyclone-v-soc-qseven-module.html > <21:57:12> "Bill - KD5TFD": awful lot of expertise in building a full blown computer board <21:57:43> "Bill - KD5TFD": an dcan you get it debugged in our lifetimes ... <22:05:12> "Bill - KD5TFD": dwim <22:05:27> "Bill - KD5TFD": dwim eax, edx <22:05:30> "Jae - K5JAE": is that called c#? From phil at pharman.org Fri Aug 22 20:31:13 2014 From: phil at pharman.org (Phil Harman) Date: Sat, 23 Aug 2014 11:31:13 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F7FD0F.6020301@alphatronique.com> References: <53F7FD0F.6020301@alphatronique.com> Message-ID: <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Hi Marc, Thanks for your email. We still have a way to go with fully proving the DFC idea but so far its looking good. We actually had this discussion a few minutes ago during the weekly Teamspeak session. Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. If such a PCB design is of interest to you then please lets discuss further. 73 Phil....VK6PH -----Original Message----- From: Marc Lalonde Sent: Saturday, August 23, 2014 10:31 AM To: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Hi guess some one already work on a ADC /DAC Board that go on the expansion connector of the DEV kit ? seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA as Glue logic.. that may remove the LAN / PHY from equation and permit made nice self contained platform ;-) if no one yet ,i may willing to help work on this ,i was a senior PCB designer whit some design backgrond .. Best 73! Marc VE2OLM On 20/08/2014 3:31 AM, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to > openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From rick at teksharp.com Sat Aug 23 06:20:21 2014 From: rick at teksharp.com (Rick Fletcher) Date: Sat, 23 Aug 2014 07:20:21 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: <00ef01cfbed5$0b5c8d00$2215a700$@teksharp.com> I'm still running V3.5 and have experienced distorted audio twice. Both times, I was able to restore normal operation by terminating PowerSDR and launching a new instance of it. 73, Rick, W7YP -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Les Keppie Sent: Friday, August 22, 2014 5:13 PM To: larry at foxgulch.com; hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable ***** High Performance Software Defined Radio Discussion List ***** Hi All I have experienced a similar situation regarding v4.1 whilst trying to revert to v4.0 After upgrading to v4.1 when it became available I only had it running for a short period when I was experiencing distorted audio - checked all bands same result - decided to revert to v4.0 firmware Using Programmer old file was reported as deleted but no perecntage values appeared when uploading the new file and the process never did complete I then switched to the Bootloader and again tried load v4.0 firmware - same result as using the Programmer This happened the day before I was due to go on 2 weeks holiday so just left everything as was On returning I thought about it for a while and decided to try the Bootloader and was able to upgrade to v4.1 and no distorted audio problems - have been running it now for some 4 days without any problems Just thought I would put this out for information Regards Les VK2DSG On Sat, 23 Aug 2014 02:41:09 +1000, Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Attempted to upgrade the firmware in my 100D using > HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when > I attempted to write 4.1 rbf, all operations stopped. Now it won't > boot. (J17 jumper on or off, doesn't help) > > So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and > fired off the Altera Quartus Programmer v12 build 177 11/7/2012 which > responded after I clicked Start as follows: > > Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 > 2014 Info (209018): Device 1 silicon ID is 0x18 Info (209044): Erasing > ASP configuration device(s) Info (209024): Programming device 1 Info > (209018): Device 1 silicon ID is 0x18 Info (209011): Successfully > performed operation(s) Info (209061): Ended Programmer operation at > Fri Aug 22 15:26:15 2014 > > which looked OK but no boot! Second from left front panel red led > glows constantly but dim. > > Somewhere I noticed (post by Franz Hegener) that I should have > selected EPC 128? My device (in the Quartus II 32 bit Programmer > window shows Device=EPCS16 as read from Quartus-II Programmer window > and also shown in the document "Quartus-II Programmer and Byteblaster" by > N9VV and KCXG v2.3 dated 04/23/13. Is this my error? > > Any ideas to try next?? > > Thanks, > Larry W0AY > > Note for record: > 1. Version 12 of the Quartus II Programmer matches the "Quartus-II > Programmer and Byteblaster" instructions (noted above) but the current > version V12 does not. Obtain V12 here: > https://www.altera.com/download/sw/dnl-sw-index.jsp# > > 2. Win7 refused to load the drivers provided by Altera in V14. I used > the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Using Opera's mail client: http://www.opera.com/mail/ _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From mlalonde at alphatronique.com Sat Aug 23 06:42:14 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Sat, 23 Aug 2014 09:42:14 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <53F89A36.4070905@alphatronique.com> Hi Phil, After some quick reading it seems that ePCI bus is Point to Point (no need for southBridge) It may sure be a good idea and let option to upgrade the Nvidia card later as tech advance. My work schedule have a bit more room on September so if there is need I will be happy to jump in. Best 73! On 22/08/2014 11:31 PM, Phil Harman wrote: > Hi Marc, > > Thanks for your email. > > We still have a way to go with fully proving the DFC idea but so far > its looking good. > > We actually had this discussion a few minutes ago during the weekly > Teamspeak session. > > Whilst the GPIO is one solution our concern is that the Jetson board > is not going to be a production item for Nvidia. There is no > guarantee that what board replaces it, be it 64 bit Jeston or > something completely different, may not have the same GIPO port. > > What does look viable is a board using miniPCIe since there is a > good possibility that future SBCs will carry this interface. > > What was suggested was a miniPCIe board with an Altera Cyclone V FPGA > (since this has PCIe implement in hardware on the chip) plus an ADC, > DAC and I/O. The I/O could include an interface to the Alex board so > we can use that rather than reproduce that hardware. > > With an FPGA on the board we have many options from DFC down to > porting the existing DDC/DUC code, which is all ready proven to work. > > If such a PCB design is of interest to you then please lets discuss > further. > > 73 Phil....VK6PH > > > > > -----Original Message----- From: Marc Lalonde > Sent: Saturday, August 23, 2014 10:31 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > guess some one already work on a ADC /DAC Board that go on the expansion > connector of the DEV kit ? > seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA > as Glue logic.. > > that may remove the LAN / PHY from equation and permit made nice self > contained platform ;-) > > if no one yet ,i may willing to help work on this ,i was a senior PCB > designer whit some design backgrond .. > > Best 73! > Marc VE2OLM > > On 20/08/2014 3:31 AM, Phil Harman wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> I'm delighted to be able to report that we have been able to develop, to >> proof-of-concept stage, a new SDR architecture. >> >> Current SDRs use the software equivalent of zero IF techniques, i.e. >> DDC, >> in order to provide (multiple) receivers. Whist this is quite >> effective, >> much of the initial DSP work is done using FPGAs, or a combination of >> FPGA >> plus dedicated DSP chips and microprocessors, rather than totally within >> the PC. >> >> As more complex features are added, the size and complexity of the FPGA >> and DSP code increases. The skills to write, debug and maintain this >> code >> is only available via a small percentage of software engineers, or >> enthusiasts, in comparison to those able to write code for PC based >> hardware. >> >> In order to open the SDR world to those with PC software skills we >> are in >> the process of developing a new SDR architecture. >> >> This architecture digitises the entire 0 to 30MHz radio spectrum in real >> time and passes the 'raw' samples directly to an associated computer. >> >> This computer then calculates the FFT of the raw samples and >> subsequently >> processes the result as the user requires. >> >> This is not a totally new concept since both the cuSDR and KISS Konsole >> software uses raw ADC samples to provide the wideband bandscope >> displays. >> >> However, for this requirement the FFT only needs to be done at the >> bandscope update rate of a few 10's of times per second, which hardly >> taxes a modern PC at all. >> >> The new concept requires that we take the FFT of all samples in >> real-time. >> >> This has been possible in the past - if you had access to a Cray super >> computer! >> >> Well now we do have access to very low cost computers that provide the >> processing power we need. One example of this is the new Nvidia Jetson >> TK1 single board computer. At a cost of $192 this board contains >> four ARM >> CPUs plus 192 CUDA processors. >> >> More details of this remarkable board can be found here: >> >> https://developer.nvidia.com/jetson-tk1 >> >> Since the CUDA cores can process data in parallel, we can use these to >> perform the high speed FFT. >> >> John, G0ORX, has written preliminary code for the Jetson board and has >> confirmed that it has the necessary performance we require. >> >> The test environment consisted of a Jetson board connected via Gigabit >> Ethernet to an Angelia board. A special version of FPGA code was >> written >> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps >> to the >> Jetson board. >> >> We used raw Ethernet frames over the Gigabit link, in order to maximise >> the link bandwidth, since we require a sustained 983Mbps transfer rate. >> >> Whilst it's still early days, and there is much more to be done, this >> critical early success does indicate that this new architecture has a >> very >> promising future. >> >> The Jetson board is taking the role of an 'SDR Server' which I have >> written about in the past. >> >> In which case what benefits does this new architecture provide to >> openHPSR? >> >> 1. The FPGA code is greatly simplified, is easier to write and maintain, >> and hence uses a small percentage of the space available with a >> subsequent >> reduction in power consumption. >> >> 2. The protocol between the SDR hardware and the SDR Server is greatly >> simplified since the SDR hardware only has to connect to a single, >> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >> required. The SDR Server simply needs to know the MAC address of the >> SDR >> hardware in order to communicate. It should be possible for a single >> SDR >> hardware board to feed multiple SDR Servers, but that's something for >> the >> future. >> >> 3. Virtually all the signal processing is undertaken on the associated >> single board computer (SBC) or (suitable) PC. If sufficient processing >> power is available then the GUI can run on the same SBC. >> Alternatively the >> user's normal PC (which does not require to be high performance since it >> does not do any significant digital signal processing) or a Tablet, cell >> phone etc could be used. >> >> 4. Many more users have the necessary skills and experience to support, >> maintain and further develop the code. New features are added to the SDR >> Server code rather than the FPGA code. >> >> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >> FPGA >> and/or power supply restrictions may have limited adding new features. >> >> 6. Future hardware upgrades will be to the associated SBC where >> faster and >> lower cost options can be expected. Nvidia have already indicated >> that a >> 64 bit board will be available in the near future. >> >> 7. Remote access to an SDR via the Internet will enable multiple >> users to >> share the SDR with each selecting their desired frequency, bandwidth and >> mode. >> >> There are other potential benefits relating to simpler and lower cost >> SDR >> hardware, but that is for the future. >> >> For want of a name we are calling this new architecture 'Direct Fourier >> Conversion' (DFC). >> >> For those that are already experimenting with the Jetson board we do >> intend to release the DFC FPGA code for both Angelia and Hermes >> boards and >> I will advise when, and where, this is available. >> >> John's code is presently not available, so please don't pester him, >> but as >> soon as it reaches Beta stage it will be released. >> >> Please join me in congratulating John on this exciting development. >> >> 73 Phil....VK6PH >> >> >> >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > From sbdick at optonline.net Sat Aug 23 08:13:24 2014 From: sbdick at optonline.net (Steven B. Dick) Date: Sat, 23 Aug 2014 11:13:24 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: Phil, as you indicated, The skills to write, debug and maintain FPGA code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. This has been a major problem in industry for years, as the cost per "line of code" is much higher for firmware vs. software for code development and maintenance, on the order of a factor of perhaps 10 to 1 for FPGA firmware vs. software written in a high order language. Note that tools such as MATLAB can be used to develop FPGA code directly rather than hand coding verilog or VHDL code but are not low cost tools. Another approach to consider is the newly emerging FPGA vendor support of high order "graphics" programming languages for their latest "System on a chip" FPGAs. Both Altera and Xilinx are now beginning to support the OpenCL programming language for their FPGAs using their latest toolsets. OpenCL is not proprietary vs. CUDA which is tied in with NVIDIA. CUDA is more mature and has a more extensive set of available libraries and a larger user community however. Although programming with OpenCL on an FPGA vs. a graphics chip using multiple graphics processing engines requires different programming approaches to take best advantages of the underlying hardware resources, this may be a way to program for "System on a chip" FPGAs, strictly in software though maintining a mix of hardware and software resources, including multiple ARM processors. Regards. "Digital Steve", K1RF -----Original Message----- All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. *********************** From rcrewson at cinci.rr.com Sat Aug 23 09:26:41 2014 From: rcrewson at cinci.rr.com (Rob Crewson) Date: Sat, 23 Aug 2014 12:26:41 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> Hi Steve, I have been looking OpenCL for a couple of months by taking some online courses. Of note is that NVidia also belongs and supports the consortium. Unfortunately in the last one of the series (just watched it today ), it mentions that a fully licensed of QuartusII is needed in order to actually get compiled code generated and loaded on a FPGA. I did not check the development board costs at that point but they are licensed for a fee as well. 73, Rob Crewson - VE3EW -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Steven B. Dick Sent: Saturday, August 23, 2014 11:13 AM To: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Phil, as you indicated, The skills to write, debug and maintain FPGA code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. This has been a major problem in industry for years, as the cost per "line of code" is much higher for firmware vs. software for code development and maintenance, on the order of a factor of perhaps 10 to 1 for FPGA firmware vs. software written in a high order language. Note that tools such as MATLAB can be used to develop FPGA code directly rather than hand coding verilog or VHDL code but are not low cost tools. Another approach to consider is the newly emerging FPGA vendor support of high order "graphics" programming languages for their latest "System on a chip" FPGAs. Both Altera and Xilinx are now beginning to support the OpenCL programming language for their FPGAs using their latest toolsets. OpenCL is not proprietary vs. CUDA which is tied in with NVIDIA. CUDA is more mature and has a more extensive set of available libraries and a larger user community however. Although programming with OpenCL on an FPGA vs. a graphics chip using multiple graphics processing engines requires different programming approaches to take best advantages of the underlying hardware resources, this may be a way to program for "System on a chip" FPGAs, strictly in software though maintining a mix of hardware and software resources, including multiple ARM processors. Regards. "Digital Steve", K1RF -----Original Message----- All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. *********************** _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From k5so at valornet.com Sat Aug 23 11:06:14 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sat, 23 Aug 2014 12:06:14 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> Message-ID: <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> A personal comment regarding FPGA programming and programming in general: The view that writing and maintaining FPGA code is beyond the capability of most of us has been blown completely out of proportion to reality! That view is simply incorrect. Indeed, I?m a good example of the point, I think. As many of you know, I am certainly not a professional programmer and, in fact, I have had no serious programming experience at all in any computer language in my life. Since joining the HPSDR community a few years ago I have managed to muddle my way along in learning how to successfully write both FPGA code and PowerSDR (C# and C) code and have discovered that it simply isn?t that hard to do. I readily admit that my code isn?t ?elegant? in the purist view but it works (sometimes anyway, hihi). The point I?m trying to make is that you only have to be willing to learn something new, that?s all, and not be too timid to give it a try to ultimately become successful in doing ANY of the programming we do. Indeed, it turns out that even the often-viewed-as-no-man?s-land of timing FPGA designs is actually completely accessible to non-professionals such as we are and, in fact, the task is easily within the grasp of the average experimenter. Further, we have always used and are still using free versions of Quartus II to create FPGA designs and load the FPGAs without problem. You don?t have to have the fully licensed Quartus II versions to do anything we wish to do with these FPGAs. Counter to what one might assume from the recent discussions, any of us can do FPGA programming with the free tools we have available from Altera if you only care to put the effort into learning how to do it. It just isn?t that hard! I?m certainly no expert in any of this stuff and would never claim to be but you don?t have to be an expert to be able to learn to work with these tools and be able to make meaningful contributions. There is no reason at all that only a small percentage of our group can do FPGA programming! The truth is that anyone can do it if you set your mind to do it. 73, Joe K5SO On Aug 23, 2014, at 10:26 AM, Rob Crewson wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Steve, > > I have been looking OpenCL for a couple of months by taking some online > courses. > Of note is that NVidia also belongs and supports the consortium. > > Unfortunately in the last one of the series (just watched it today ), it > mentions that a fully licensed of QuartusII > is needed in order to actually get compiled code generated and loaded on > a FPGA. > > I did not check the development board costs at that point but they are > licensed for a fee as well. > > 73, > > Rob Crewson - VE3EW > > > > -----Original Message----- > From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Steven > B. Dick > Sent: Saturday, August 23, 2014 11:13 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > ***** High Performance Software Defined Radio Discussion List ***** > > Phil, as you indicated, The skills to write, debug and maintain FPGA code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. This has been a major problem in industry for years, as the cost > per "line of code" is much higher for firmware vs. software for code > development and maintenance, on the order of a factor of perhaps 10 to 1 for > FPGA firmware vs. software written in a high order language. Note that > tools such as MATLAB can be used to develop FPGA code directly rather than > hand coding verilog or VHDL code but are not low cost tools. > > Another approach to consider is the newly emerging FPGA vendor support of > high order "graphics" programming languages for their latest "System on a > chip" FPGAs. Both Altera and Xilinx are now beginning to support the OpenCL > programming language for their FPGAs using their latest toolsets. OpenCL is > not proprietary vs. CUDA which is tied in with NVIDIA. CUDA is more mature > and has a more extensive set of available libraries and a larger user > community however. Although programming with OpenCL on an FPGA vs. a > graphics chip using multiple graphics processing engines requires different > programming approaches to take best advantages of the underlying hardware > resources, this may be a way to program for "System on a chip" FPGAs, > strictly in software though maintining a mix of hardware and software > resources, including multiple ARM processors. > > Regards. "Digital Steve", K1RF > > -----Original Message----- > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within the > PC. > > As more complex features are added, the size and complexity of the FPGA and > DSP code increases. The skills to write, debug and maintain this code is > only available via a small percentage of software engineers, or enthusiasts, > in comparison to those able to write code for PC based hardware. > > *********************** > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From sbdick at optonline.net Sat Aug 23 12:10:10 2014 From: sbdick at optonline.net (Steven B. Dick) Date: Sat, 23 Aug 2014 15:10:10 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> Message-ID: <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with a desire to learn and my hat is off to you for taking it upon yourself to learn both firmware and software programming. That was not the point I was trying to make. In my previous life, I was a digital design manager. FPGA code designed by experienced senior FPGA designers took a lot more time to develop (even worse to maintain) compared to software written by experienced software developers which ran on general purpose compute nodes. For many years, FPGA designs had an important role to play where special functions just could not be done in general purpose processors or even DSP processors with comparable performance, but one willingly paid for it in reaping the benefits of high performance and/or greatly reduced hardware footprint. But the processing landscape is changing nowadays with very low cost processing platforms based on multiple node graphics engines coupled with high order language support with DSP libraries. Use of these platforms is starting to result in huge performance capabilities in a low cost rapid development environment if these platforms can be readily used for particular applications including the FFT function. Regards, "Digital Steve", K1RF -----Original Message----- From: Joe Martin K5SO [mailto:k5so at valornet.com] Sent: Saturday, August 23, 2014 2:06 PM To: Rob Crewson Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development A personal comment regarding FPGA programming and programming in general: The view that writing and maintaining FPGA code is beyond the capability of most of us has been blown completely out of proportion to reality! That view is simply incorrect. Indeed, I'm a good example of the point, I think. From k5so at valornet.com Sat Aug 23 12:23:43 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sat, 23 Aug 2014 13:23:43 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> Message-ID: <260DD696-CE58-4F14-A24E-55B5FFCCDC3F@valornet.com> There are many such sources for information. To learn the basics of the Verilog language, which is what we use to write the FPGA code designs, Kirk Weedman KD7IRS some years ago kindly put together a beginners course tailored to the HPSDR project. The course is available for download on the HPSDR webpage below: http://verilog.openhpsdr.org However, in my experience the absolute best way to learn how to do this is by downloading Quartus II, installing it on your computer, and using it to examine an existing HPSDR firmware design. By examing an actual firmware design that we are using today you can see how the various tasks are accomplished in the code. We try to comment the code as much as is practical in order to help us remember what each section does but also to help newcomers understand what the code section is doing. You can spend lots of unnecessary time attending/viewing classes which will be giving you much info regarding Verilog syntax, etc, but you can also get the idea very quickly by examining an actual firmware design by using the Quartus II editor. In addition, you?ll immediately be learning how to use the Quartus II tool. In short, my view that the absolute best way to learn is to get your feet wet immediately with the tool that you will be using; i.e., Quartus II, to examine an existing firmware design. The primary issue to understand about FPGA code, in my view, is to realize from the start that each little section of code within the firmware design runs in parallel with every other section. That is, the code execution is not ?event driven? as it is in Windows programming nor is it strictly running lines of code sequentially as in some languages (except within each section of code in the firmare design). Because of this it is actually easy to take one little section of code and examine it carefully to see what it is doing, how it is doing it, and what syntax is used to accomplish it. After you feel you understand a portion of it then you can make small changes to it, compile it, and see what effect your change(s) have on the performance of the firmware design by actually loading it into your HPSDR rigs? FPGA. Plus you immediately gain experience in how to do all that. Sure, you?ll make mistakes! But be assured that anything you do is recoverable; you can?t hurt the FPGA by misprogramming it. 73, Joe K5SO On Aug 23, 2014, at 12:46 PM, Neal Campbell wrote: > Are there any good beginner courses on the internet? > > 73 > > Neal Campbell > Abroham Neal LLC > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Sat Aug 23 12:46:38 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sat, 23 Aug 2014 13:46:38 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> Message-ID: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> Hi Steve, RR, understood. I appreciate your point. But as you noted, the landscape has changed and is continually changing such that the world of FPGA programming is not limited to those senior FPGA programmers anymore. Granted, who knows if or how long FPGAs will be important, but for our project right now and for the forseeable future they are central to our designs. Therefore, it should be understood by all that the domain of FPGA programming is certainly not now limited to ?senior FPGA programmers?. We can successfully do such programming ourselves if we want to do it. 73, Joe K5SO On Aug 23, 2014, at 1:10 PM, Steven B. Dick wrote: > Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with > a desire to learn and my hat is off to you for taking it upon yourself to > learn both firmware and software programming. That was not the point I was > trying to make. In my previous life, I was a digital design manager. FPGA > code designed by experienced senior FPGA designers took a lot more time to > develop (even worse to maintain) compared to software written by experienced > software developers which ran on general purpose compute nodes. For many > years, FPGA designs had an important role to play where special functions > just could not be done in general purpose processors or even DSP processors > with comparable performance, but one willingly paid for it in reaping the > benefits of high performance and/or greatly reduced hardware footprint. But > the processing landscape is changing nowadays with very low cost processing > platforms based on multiple node graphics engines coupled with high order > language support with DSP libraries. Use of these platforms is starting to > result in huge performance capabilities in a low cost rapid development > environment if these platforms can be readily used for particular > applications including the FFT function. > > Regards, > "Digital Steve", K1RF > > -----Original Message----- > From: Joe Martin K5SO [mailto:k5so at valornet.com] > Sent: Saturday, August 23, 2014 2:06 PM > To: Rob Crewson > Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > A personal comment regarding FPGA programming and programming in general: > > The view that writing and maintaining FPGA code is beyond the capability of > most of us has been blown completely out of proportion to reality! That > view is simply incorrect. > > Indeed, I'm a good example of the point, I think. > From n9vv at wowway.com Sat Aug 23 16:13:32 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Sat, 23 Aug 2014 18:13:32 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> Message-ID: <53F9201C.8050306@wowway.com> P.S. I think Joe has a 4 digit IQ and he is just too polite to tell us!! 73 de Ken N9VV On 8/23/2014 2:46 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Steve, > > RR, understood. I appreciate your point. > > But as you noted, the landscape has changed and is continually changing such that the world of FPGA programming is not limited to those senior FPGA programmers anymore. Granted, who knows if or how long FPGAs will be important, but for our project right now and for the forseeable future they are central to our designs. Therefore, it should be understood by all that the domain of FPGA programming is certainly not now limited to ?senior FPGA programmers?. We can successfully do such programming ourselves if we want to do it. > > 73, Joe K5SO > > On Aug 23, 2014, at 1:10 PM, Steven B. Dick wrote: > >> Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with >> a desire to learn and my hat is off to you for taking it upon yourself to >> learn both firmware and software programming. That was not the point I was >> trying to make. In my previous life, I was a digital design manager. FPGA >> code designed by experienced senior FPGA designers took a lot more time to >> develop (even worse to maintain) compared to software written by experienced >> software developers which ran on general purpose compute nodes. For many >> years, FPGA designs had an important role to play where special functions >> just could not be done in general purpose processors or even DSP processors >> with comparable performance, but one willingly paid for it in reaping the >> benefits of high performance and/or greatly reduced hardware footprint. But >> the processing landscape is changing nowadays with very low cost processing >> platforms based on multiple node graphics engines coupled with high order >> language support with DSP libraries. Use of these platforms is starting to >> result in huge performance capabilities in a low cost rapid development >> environment if these platforms can be readily used for particular >> applications including the FFT function. >> >> Regards, >> "Digital Steve", K1RF >> >> -----Original Message----- >> From: Joe Martin K5SO [mailto:k5so at valornet.com] >> Sent: Saturday, August 23, 2014 2:06 PM >> To: Rob Crewson >> Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org >> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >> >> A personal comment regarding FPGA programming and programming in general: >> >> The view that writing and maintaining FPGA code is beyond the capability of >> most of us has been blown completely out of proportion to reality! That >> view is simply incorrect. >> >> Indeed, I'm a good example of the point, I think. >> > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From w4yn at earthlink.net Sat Aug 23 16:18:39 2014 From: w4yn at earthlink.net (Tim ORourke) Date: Sat, 23 Aug 2014 19:18:39 -0400 (GMT-04:00) Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <11504088.1408835920124.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> I think all the guys doing this are 4 digit geeks! And that's a great attribute IMHO! Tim Tim O\Rourke W4YN at ARRL.Net Low Power Amateur Radio Rocks Member of Flying Pigs,ARCI,GQRP,RSGB,ARRL Life Member R/C Pilot (sort of) NRA Life Member NRA Certified Rifle, Pistol, Black Powder Instructor, Range Officer -----Original Message----- >From: "Ken N9VV (Win-7/64)" >Sent: Aug 23, 2014 7:13 PM >To: hpsdr at lists.openhpsdr.org >Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > >***** High Performance Software Defined Radio Discussion List ***** > >P.S. I think Joe has a 4 digit IQ and he is just too polite to tell us!! > >73 de Ken N9VV > >On 8/23/2014 2:46 PM, Joe Martin K5SO wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Steve, >> >> RR, understood. I appreciate your point. >> >> But as you noted, the landscape has changed and is continually changing such that the world of FPGA programming is not limited to those senior FPGA programmers anymore. Granted, who knows if or how long FPGAs will be important, but for our project right now and for the forseeable future they are central to our designs. Therefore, it should be understood by all that the domain of FPGA programming is certainly not now limited to ?senior FPGA programmers?. We can successfully do such programming ourselves if we want to do it. >> >> 73, Joe K5SO >> >> On Aug 23, 2014, at 1:10 PM, Steven B. Dick wrote: >> >>> Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with >>> a desire to learn and my hat is off to you for taking it upon yourself to >>> learn both firmware and software programming. That was not the point I was >>> trying to make. In my previous life, I was a digital design manager. FPGA >>> code designed by experienced senior FPGA designers took a lot more time to >>> develop (even worse to maintain) compared to software written by experienced >>> software developers which ran on general purpose compute nodes. For many >>> years, FPGA designs had an important role to play where special functions >>> just could not be done in general purpose processors or even DSP processors >>> with comparable performance, but one willingly paid for it in reaping the >>> benefits of high performance and/or greatly reduced hardware footprint. But >>> the processing landscape is changing nowadays with very low cost processing >>> platforms based on multiple node graphics engines coupled with high order >>> language support with DSP libraries. Use of these platforms is starting to >>> result in huge performance capabilities in a low cost rapid development >>> environment if these platforms can be readily used for particular >>> applications including the FFT function. >>> >>> Regards, >>> "Digital Steve", K1RF >>> >>> -----Original Message----- >>> From: Joe Martin K5SO [mailto:k5so at valornet.com] >>> Sent: Saturday, August 23, 2014 2:06 PM >>> To: Rob Crewson >>> Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org >>> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >>> >>> A personal comment regarding FPGA programming and programming in general: >>> >>> The view that writing and maintaining FPGA code is beyond the capability of >>> most of us has been blown completely out of proportion to reality! That >>> view is simply incorrect. >>> >>> Indeed, I'm a good example of the point, I think. >>> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >_______________________________________________ >HPSDR Discussion List >To post msg: hpsdr at openhpsdr.org >Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >HPSDR web page: http://openhpsdr.org >Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From scotty at tonks.com Sat Aug 23 16:43:31 2014 From: scotty at tonks.com (Scott Cowling) Date: Sat, 23 Aug 2014 16:43:31 -0700 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <260DD696-CE58-4F14-A24E-55B5FFCCDC3F@valornet.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> <260DD696-CE58-4F14-A24E-55B5FFCCDC3F@valornet.com> Message-ID: <53F92723.8020105@tonks.com> I want to echo Joe's sentiments on FPGA development exactly. In many respects, getting started in FPGA programming is *easier* than jumping into C++ programming. When you download the tools, the environment is all set up for you. You do not need to try to figure out which toolset to use, where to get it, how to configure it, etc. There are many excellent references and tutorials available for learning Verilog. If you are already a hardware designer, it is even easier, since Verilog synthesis constructs generate hardware. You can start out with the simple constructs, then learn and use more "elegant" style as you go. The absolute best way to start is by reading, understanding and modifying existing code examples. The SDRstick BeRadio FPGA design is a good starting place. Look in svn.sdrstick.com under "sdrstick-release/beradio/beradio-firmware/source". This is a commented, stand-alone AM radio design in Verilog. You can even get hardware to run it on if you like, but it is not necessary; there is benefit to gain just by studying the sample code. There are small FPGA development kits for as little as $49 if you want to try your hand at writing a "Hello LED" program (the hardware equivalent of the beginning C programmer's "Hello World" program). The two main things to remember are: 1. don't be afraid to jump right in 2. take it slowly and *have fun* I have been programming FPGAs since the 1980s, and it is *still* fun! 73, Scotty WA2DFI On 2014-08-23 12:23, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > There are many such sources for information. To learn the basics of the > Verilog language, which is what we use to write the FPGA code designs, > Kirk Weedman KD7IRS some years ago kindly put together a beginners > course tailored to the HPSDR project. The course is available for > download on the HPSDR webpage below: > > http://verilog.openhpsdr.org > > However, in my experience the absolute best way to learn how to do this > is by downloading Quartus II, installing it on your computer, and using > it to examine an existing HPSDR firmware design. By examing an actual > firmware design that we are using today you can see how the various > tasks are accomplished in the code. We try to comment the code as much > as is practical in order to help us remember what each section does but > also to help newcomers understand what the code section is doing. > > You can spend lots of unnecessary time attending/viewing classes which > will be giving you much info regarding Verilog syntax, etc, but you can > also get the idea very quickly by examining an actual firmware design by > using the Quartus II editor. In addition, you?ll immediately be > learning how to use the Quartus II tool. In short, my view that the > absolute best way to learn is to get your feet wet immediately with the > tool that you will be using; i.e., Quartus II, to examine an existing > firmware design. > > The primary issue to understand about FPGA code, in my view, is to > realize from the start that each little section of code within the > firmware design runs in parallel with every other section. That is, the > code execution is not ?event driven? as it is in Windows programming nor > is it strictly running lines of code sequentially as in some languages > (except within each section of code in the firmare design). Because of > this it is actually easy to take one little section of code and examine > it carefully to see what it is doing, how it is doing it, and what > syntax is used to accomplish it. > > After you feel you understand a portion of it then you can make small > changes to it, compile it, and see what effect your change(s) have on > the performance of the firmware design by actually loading it into your > HPSDR rigs? FPGA. Plus you immediately gain experience in how to do all > that. Sure, you?ll make mistakes! But be assured that anything you do > is recoverable; you can?t hurt the FPGA by misprogramming it. > > 73, Joe K5SO > > On Aug 23, 2014, at 12:46 PM, Neal Campbell wrote: > >> Are there any good beginner courses on the internet? >> >> 73 >> >> Neal Campbell >> Abroham Neal LLC >> >> >> > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From brian13434 at yahoo.co.uk Sun Aug 24 05:38:15 2014 From: brian13434 at yahoo.co.uk (Brian D) Date: Sun, 24 Aug 2014 13:38:15 +0100 Subject: [hpsdr] Angelia_v4.2 firmware release In-Reply-To: References: Message-ID: Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > Angelia_v4.2 firmware is available for download from > > http://k5so.com/HPSDR_downloads.html > Is this suitable for use in the ANAN range of tranceivers or does it need to be changed by Abhi for the different filter frequencies? -- Brian D G3VGZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From k5so at valornet.com Sun Aug 24 06:30:01 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 24 Aug 2014 07:30:01 -0600 Subject: [hpsdr] Angelia_v4.2 firmware release In-Reply-To: References: Message-ID: Hi Brian, The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. The firmware uses correct switch-point frequencies for the Alex filter set, which is also the correct switch-point frequencies for the ANAN-series radios that have the correct windings on their filters. It is my understanding that later versions of the ANAN series radios use correct windings on their 10/12m filters so their switch points should be identical to those in Alex. Earlier versions of the ANAN series radios do not. The firmware ?patch? used initially by Abhi to correct the 10m low power output for some ANAN series radios is not the ideal method for correcting the issue of low power output on 10m on those earlier ANAN radios, as the issue is actually a hardware issue, not a firmware or software issue. If Abhi wishes to create a version of firmware that uses different switch points from Alex that?s his prerogative but you should be aware that the issue is not actually a firmware issue, it?s a hardware issue. The fact is that there should be only a single firmware version to use with each of the Hermes, Angelia, and Orion boards, respectively, regardless of whether the board are used in an ANAN-series configuration with the Apache Labs filters or in a stand alone configuration using Alex filters. The "correct fix? for ANAN radios that have the low power output issue on 10m is to rewind the filter toroids for the 10/12 m filters on those radios, not to patch the firmware or software to use switch points that are different from the Alex filter design. 73, Joe K5SO On Aug 24, 2014, at 6:38 AM, Brian D wrote: > Joe Martin K5SO wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> Angelia_v4.2 firmware is available for download from >> >> http://k5so.com/HPSDR_downloads.html >> > Is this suitable for use in the ANAN range of tranceivers or does it need to > be changed by Abhi for the different filter frequencies? > > -- > Brian D > G3VGZ > > --- > This email is free from viruses and malware because avast! Antivirus protection is active. > http://www.avast.com > From k5so at valornet.com Sun Aug 24 06:43:04 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 24 Aug 2014 07:43:04 -0600 Subject: [hpsdr] Angelia_v4.2 firmware release In-Reply-To: References: Message-ID: > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. Excuse me. A more accurate statement would?ve been: "The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience a lower maximum output power on 10m than you will if the windings are correct.? 73, Joe K5SO On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Brian, > > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. > > The firmware uses correct switch-point frequencies for the Alex filter set, which is also the correct switch-point frequencies for the ANAN-series radios that have the correct windings on their filters. It is my understanding that later versions of the ANAN series radios use correct windings on their 10/12m filters so their switch points should be identical to those in Alex. Earlier versions of the ANAN series radios do not. > > The firmware ?patch? used initially by Abhi to correct the 10m low power output for some ANAN series radios is not the ideal method for correcting the issue of low power output on 10m on those earlier ANAN radios, as the issue is actually a hardware issue, not a firmware or software issue. If Abhi wishes to create a version of firmware that uses different switch points from Alex that?s his prerogative but you should be aware that the issue is not actually a firmware issue, it?s a hardware issue. > > The fact is that there should be only a single firmware version to use with each of the Hermes, Angelia, and Orion boards, respectively, regardless of whether the board are used in an ANAN-series configuration with the Apache Labs filters or in a stand alone configuration using Alex filters. The "correct fix? for ANAN radios that have the low power output issue on 10m is to rewind the filter toroids for the 10/12 m filters on those radios, not to patch the firmware or software to use switch points that are different from the Alex filter design. > > > 73, Joe K5SO > > On Aug 24, 2014, at 6:38 AM, Brian D wrote: > >> Joe Martin K5SO wrote: >> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> All, >>> >>> Angelia_v4.2 firmware is available for download from >>> >>> http://k5so.com/HPSDR_downloads.html >>> >> Is this suitable for use in the ANAN range of tranceivers or does it need to >> be changed by Abhi for the different filter frequencies? >> >> -- >> Brian D >> G3VGZ >> >> --- >> This email is free from viruses and malware because avast! Antivirus protection is active. >> http://www.avast.com >> > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From bjablonski at att.net Sun Aug 24 11:33:14 2014 From: bjablonski at att.net (Barry Jablonski) Date: Sun, 24 Aug 2014 14:33:14 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> Message-ID: <53FA2FEA.1080501@att.net> Hi Joe, I should know this, but -- where is the FPGA source code located? Barry WB2ZXJ From wb9qzb_groups at yahoo.com Sun Aug 24 11:34:29 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Sun, 24 Aug 2014 11:34:29 -0700 Subject: [hpsdr] Banquet Speaker & Sunday Seminar Annouced at ARRL/TAPR DCC (Digital Communications Conference), Austin, TX, 9/5 - 9/7 In-Reply-To: <1408905113.46795.YahooMailNeo@web140204.mail.bf1.yahoo.com> References: <53EDF934.8040708@sbcglobal.net> <1408905113.46795.YahooMailNeo@web140204.mail.bf1.yahoo.com> Message-ID: <1408905269.81493.YahooMailNeo@web140204.mail.bf1.yahoo.com> The 2014 ARRL/TAPR DCC?Saturday Night Banquet Speaker & Topic?will be? Gerald Youngblood, K5SDR presenting?"Accidental Company, the making of Flex Radio" ----- Forwarded Message ----- From: Stan Horzepa To: tapr-announce at tapr.org Sent: Friday, August 15, 2014 7:12 AM Subject: [tapr-announce] DCC in 3 weeks The 2014 ?ARRL/TAPR DCC will be on Friday, September 5th through Sunday, September 7th at the Austin Marriott South in Austin, Texas. The DCC has two days of technical forums on Friday and Saturday and a concurrent introductory forum on Saturday.? On Saturday night, the banquet will feature an interesting speaker andthe Sunday morning seminar will be "Introduction to SoC FPGA Programming for Mixed Signal Systems" by Chris Testa, KD2BMH. There will be free tables in the demo room to demonstrate projects and vendors to demonstrate products. Time is running out, so those interested in attending should register for the DCC and make hotel reservations ASAP. More DCC information is available at:?www.tapr.org/dcc? ? _______________________________________________ tapr-announce mailing list -------------- next part -------------- An HTML attachment was scrubbed... URL: From pa5bw at xs4all.nl Sun Aug 24 11:55:16 2014 From: pa5bw at xs4all.nl (Ben Witvliet) Date: Sun, 24 Aug 2014 20:55:16 +0200 Subject: [hpsdr] QSK question Message-ID: <81f5d1436d8c0bb8218afb700688ca0a.squirrel@webmail.xs4all.nl> Dear all, I hesistating to switch from my FT990 to an ANAN-200D as my primary RIG as I love the superb quality of the HPSDR receiver and I got hooked on the overview that the waterfall display offer. But I'm also a fanatic DX-er and CW QSK adept, and therefore CAN't LIVE without QSK ;-) I had Erik PA3DES demonstrate the ANAN-10D (HPSDR Hermes) to me with QSK on, but we could not get it working properly. Of course with paddle and headphones connected directly to the ANAN hardware. The switching seems fast enough, but after every dash or dit the AGC of the receiver has to slowly come back to normal, making it impossible to hear anything in between the CW symbols. (1) Any experienced HPSDR user and CW-er here that can tell me what settings we have wrong? (2) Any HPSDR user in The Netherlands that has experience with HF DX-ing in CW and with QSK willing to give a demo of his HPSDR station? Kindest regards, 73, Ben PE5B / PA5BW / 5R8DS From k5so at valornet.com Sun Aug 24 13:07:25 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 24 Aug 2014 14:07:25 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53FA2FEA.1080501@att.net> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> <53FA2FEA.1080501@att.net> Message-ID: <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> Hi Barry, The source code for all of the OpenHPSDR boards is located on the SVN. For Hermes as an example, the source code can be found at http://svn.tapr.org/repos_sdr_hpsdr/trunk/Hermes/Source/Hermes_v2.9/Heremes_v2.9.qar Similarly for Metis, Ozy, Mercury, and Penelope. For Angelia and Orion the source code is available on both my website download page within the firmware download zipped folder http://k5so.com/HPSDR_downloads.html and the Apache Labs download page (sorry, I don?t have the URL for that handy). The source code is generally stored in the form of a *.qar file, which is the Quartus II archive file format. It can be opened and edited and re-compiled if you wish using Quartus II. 73, Joe K5SO On Aug 24, 2014, at 12:33 PM, Barry Jablonski wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Joe, > > I should know this, but -- where is the FPGA source code located? > > Barry > WB2ZXJ From bjablonski at att.net Sun Aug 24 13:20:31 2014 From: bjablonski at att.net (Barry Jablonski) Date: Sun, 24 Aug 2014 16:20:31 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> <53FA2FEA.1080501@att.net> <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> Message-ID: <53FA490F.9040102@att.net> Thank you very much Joe for the info. I guess that I will have to reinstall Tortoise SVN on the Win7/64 Pro machine. It was on the old XP/32 SP3 box, but I failed to bring it forward. Barry WB2ZXJ On 8/24/2014 4:07 PM, Joe Martin K5SO wrote: > Hi Barry, > > The source code for all of the OpenHPSDR boards is located on the SVN. For Hermes as an example, the source code can be found at > > http://svn.tapr.org/repos_sdr_hpsdr/trunk/Hermes/Source/Hermes_v2.9/Heremes_v2.9.qar > > Similarly for Metis, Ozy, Mercury, and Penelope. > > For Angelia and Orion the source code is available on both my website download page within the firmware download zipped folder > > http://k5so.com/HPSDR_downloads.html > > and the Apache Labs download page (sorry, I don?t have the URL for that handy). > > The source code is generally stored in the form of a *.qar file, which is the Quartus II archive file format. It can be opened and edited and re-compiled if you wish using Quartus II. > > 73, Joe K5SO > > On Aug 24, 2014, at 12:33 PM, Barry Jablonski wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Joe, >> >> I should know this, but -- where is the FPGA source code located? >> >> Barry >> WB2ZXJ > From lstoskopf at cox.net Sun Aug 24 15:52:53 2014 From: lstoskopf at cox.net (lstoskopf at cox.net) Date: Sun, 24 Aug 2014 18:52:53 -0400 Subject: [hpsdr] Buy Jetson board? Message-ID: <20140824185253.KI4BB.171489.imail@eastrmwml114> Scotty has the new processor board coming out for his boards and I'm on board (!) when they are out. Ending up here with a pile of development boards (I don't mind). Is there enough SDR coming out/planned to buy a Jetson board and be a passive user or wait for the bigger version or ????????? Fun to try to keep up with the bleeding edge. N0UU From kv0s.dave at gmail.com Sun Aug 24 16:48:36 2014 From: kv0s.dave at gmail.com (Dave Larsen) Date: Sun, 24 Aug 2014 18:48:36 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53FA490F.9040102@att.net> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> <53FA2FEA.1080501@att.net> <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> <53FA490F.9040102@att.net> Message-ID: Barry - Just to let you and others know SVN Software works but you can download files one at time from the web interface and since all tha verlog file are in a *.qar file it may be easier to just use the web interface svn.tapr.org Dave KV0S On Aug 24, 2014 3:20 PM, "Barry Jablonski" wrote: > Thank you very much Joe for the info. > > I guess that I will have to reinstall Tortoise SVN on the Win7/64 Pro > machine. It was on the old XP/32 SP3 box, but I failed to bring it forward. > > Barry > WB2ZXJ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gokoyev+k3it at gmail.com Mon Aug 25 08:43:55 2014 From: gokoyev+k3it at gmail.com (k3it) Date: Mon, 25 Aug 2014 11:43:55 -0400 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) Message-ID: Is there an easy way to identify which radios need a correction for 10/12m coils? Vasiliy On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > The short answer is yes, but if you happen to have an ANAN-series radio > that has incorrect number of windings on the 10/12m filter toroids you will > experience low output power on 10m. > > > Excuse me. A more accurate statement would?ve been: > > "The short answer is yes, but if you happen to have an ANAN-series radio > that has incorrect number of windings on the 10/12m filter toroids you will > experience a lower maximum output power on 10m than you will if the > windings are correct.? > > 73, Joe K5SO > > > On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: > > > ***** High Performance Software Defined Radio Discussion List ***** > > > > Hi Brian, > > > > The short answer is yes, but if you happen to have an ANAN-series radio > that has incorrect number of windings on the 10/12m filter toroids you will > experience low output power on 10m. > > > > The firmware uses correct switch-point frequencies for the Alex filter > set, which is also the correct switch-point frequencies for the ANAN-series > radios that have the correct windings on their filters. It is my > understanding that later versions of the ANAN series radios use correct > windings on their 10/12m filters so their switch points should be identical > to those in Alex. Earlier versions of the ANAN series radios do not. > > > > The firmware ?patch? used initially by Abhi to correct the 10m low power > output for some ANAN series radios is not the ideal method for correcting > the issue of low power output on 10m on those earlier ANAN radios, as the > issue is actually a hardware issue, not a firmware or software issue. If > Abhi wishes to create a version of firmware that uses different switch > points from Alex that?s his prerogative but you should be aware that the > issue is not actually a firmware issue, it?s a hardware issue. > > > > The fact is that there should be only a single firmware version to use > with each of the Hermes, Angelia, and Orion boards, respectively, > regardless of whether the board are used in an ANAN-series configuration > with the Apache Labs filters or in a stand alone configuration using Alex > filters. The "correct fix? for ANAN radios that have the low power output > issue on 10m is to rewind the filter toroids for the 10/12 m filters on > those radios, not to patch the firmware or software to use switch points > that are different from the Alex filter design. > > > > > > 73, Joe K5SO > > > > On Aug 24, 2014, at 6:38 AM, Brian D wrote: > > > >> Joe Martin K5SO wrote: > >> > >>> ***** High Performance Software Defined Radio Discussion List ***** > >>> > >>> All, > >>> > >>> Angelia_v4.2 firmware is available for download from > >>> > >>> http://k5so.com/HPSDR_downloads.html > >>> > >> Is this suitable for use in the ANAN range of tranceivers or does it > need to > >> be changed by Abhi for the different filter frequencies? > >> > >> -- > >> Brian D > >> G3VGZ > >> > >> --- > >> This email is free from viruses and malware because avast! Antivirus > protection is active. > >> http://www.avast.com > >> > > > > _______________________________________________ > > HPSDR Discussion List > > To post msg: hpsdr at openhpsdr.org > > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > > HPSDR web page: http://openhpsdr.org > > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 25 09:25:10 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 25 Aug 2014 10:25:10 -0600 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: It is my understanding that L15 should have 8 turns and L16 should have 9 turns, both of 22 AWG wire. If they do not, then you may observe a lower output power on 10m Tx than you would otherwise. 73, Joe K5SO On Aug 25, 2014, at 9:43 AM, k3it wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Is there an easy way to identify which radios need a correction for 10/12m coils? > > Vasiliy > > > On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. > > > Excuse me. A more accurate statement would?ve been: > > "The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience a lower maximum output power on 10m than you will if the windings are correct.? > > 73, Joe K5SO > > > On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: > > > ***** High Performance Software Defined Radio Discussion List ***** > > > > Hi Brian, > > > > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. > > > > The firmware uses correct switch-point frequencies for the Alex filter set, which is also the correct switch-point frequencies for the ANAN-series radios that have the correct windings on their filters. It is my understanding that later versions of the ANAN series radios use correct windings on their 10/12m filters so their switch points should be identical to those in Alex. Earlier versions of the ANAN series radios do not. > > > > The firmware ?patch? used initially by Abhi to correct the 10m low power output for some ANAN series radios is not the ideal method for correcting the issue of low power output on 10m on those earlier ANAN radios, as the issue is actually a hardware issue, not a firmware or software issue. If Abhi wishes to create a version of firmware that uses different switch points from Alex that?s his prerogative but you should be aware that the issue is not actually a firmware issue, it?s a hardware issue. > > > > The fact is that there should be only a single firmware version to use with each of the Hermes, Angelia, and Orion boards, respectively, regardless of whether the board are used in an ANAN-series configuration with the Apache Labs filters or in a stand alone configuration using Alex filters. The "correct fix? for ANAN radios that have the low power output issue on 10m is to rewind the filter toroids for the 10/12 m filters on those radios, not to patch the firmware or software to use switch points that are different from the Alex filter design. > > > > > > 73, Joe K5SO > > > > On Aug 24, 2014, at 6:38 AM, Brian D wrote: > > > >> Joe Martin K5SO wrote: > >> > >>> ***** High Performance Software Defined Radio Discussion List ***** > >>> > >>> All, > >>> > >>> Angelia_v4.2 firmware is available for download from > >>> > >>> http://k5so.com/HPSDR_downloads.html > >>> > >> Is this suitable for use in the ANAN range of tranceivers or does it need to > >> be changed by Abhi for the different filter frequencies? > >> > >> -- > >> Brian D > >> G3VGZ > >> > >> --- > >> This email is free from viruses and malware because avast! Antivirus protection is active. > >> http://www.avast.com > >> > > > > _______________________________________________ > > HPSDR Discussion List > > To post msg: hpsdr at openhpsdr.org > > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > > HPSDR web page: http://openhpsdr.org > > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 25 09:36:31 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 25 Aug 2014 10:36:31 -0600 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: <2E9C3C33-83C3-4A84-A93C-24EEBD89753C@valornet.com> References: <2E9C3C33-83C3-4A84-A93C-24EEBD89753C@valornet.com> Message-ID: It is my further understanding that radios that have the 100W PA and were shipped after March 2014 have the correct number of windings on the 10/12m LPF toroids. 73, Joe K5SO On Aug 25, 2014, at 10:25 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > It is my understanding that L15 should have 8 turns and L16 should have 9 turns, both of 22 AWG wire. > > If they do not, then you may observe a lower output power on 10m Tx than you would otherwise. > > 73, Joe K5SO > > > On Aug 25, 2014, at 9:43 AM, k3it wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Is there an easy way to identify which radios need a correction for 10/12m coils? >> >> Vasiliy > From abhiarunoday at gmail.com Mon Aug 25 09:53:03 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Mon, 25 Aug 2014 22:23:03 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: Hi Vasiliy, The Original Angelia/Orion firmware extends the 17/15M LPF upto 27Mhz so that 12M is incorporated within this LPF, the Hermes firmware is modified to the (B) version by me to enable this, Firmware that you download from the Apache website incorporates this change, 73s, Abhi On Mon, Aug 25, 2014 at 9:13 PM, k3it wrote: > Is there an easy way to identify which radios need a correction for 10/12m > coils? > > Vasiliy > > > On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO > wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> >> >> Excuse me. A more accurate statement would?ve been: >> >> "The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience a lower maximum output power on 10m than you will if the >> windings are correct.? >> >> 73, Joe K5SO >> >> >> On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: >> >> > ***** High Performance Software Defined Radio Discussion List ***** >> > >> > Hi Brian, >> > >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> > >> > The firmware uses correct switch-point frequencies for the Alex filter >> set, which is also the correct switch-point frequencies for the ANAN-series >> radios that have the correct windings on their filters. It is my >> understanding that later versions of the ANAN series radios use correct >> windings on their 10/12m filters so their switch points should be identical >> to those in Alex. Earlier versions of the ANAN series radios do not. >> > >> > The firmware ?patch? used initially by Abhi to correct the 10m low >> power output for some ANAN series radios is not the ideal method for >> correcting the issue of low power output on 10m on those earlier ANAN >> radios, as the issue is actually a hardware issue, not a firmware or >> software issue. If Abhi wishes to create a version of firmware that uses >> different switch points from Alex that?s his prerogative but you should be >> aware that the issue is not actually a firmware issue, it?s a hardware >> issue. >> > >> > The fact is that there should be only a single firmware version to use >> with each of the Hermes, Angelia, and Orion boards, respectively, >> regardless of whether the board are used in an ANAN-series configuration >> with the Apache Labs filters or in a stand alone configuration using Alex >> filters. The "correct fix? for ANAN radios that have the low power output >> issue on 10m is to rewind the filter toroids for the 10/12 m filters on >> those radios, not to patch the firmware or software to use switch points >> that are different from the Alex filter design. >> > >> > >> > 73, Joe K5SO >> > >> > On Aug 24, 2014, at 6:38 AM, Brian D wrote: >> > >> >> Joe Martin K5SO wrote: >> >> >> >>> ***** High Performance Software Defined Radio Discussion List ***** >> >>> >> >>> All, >> >>> >> >>> Angelia_v4.2 firmware is available for download from >> >>> >> >>> http://k5so.com/HPSDR_downloads.html >> >>> >> >> Is this suitable for use in the ANAN range of tranceivers or does it >> need to >> >> be changed by Abhi for the different filter frequencies? >> >> >> >> -- >> >> Brian D >> >> G3VGZ >> >> >> >> --- >> >> This email is free from viruses and malware because avast! Antivirus >> protection is active. >> >> http://www.avast.com >> >> >> > >> > _______________________________________________ >> > HPSDR Discussion List >> > To post msg: hpsdr at openhpsdr.org >> > Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> > HPSDR web page: http://openhpsdr.org >> > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhiarunoday at gmail.com Mon Aug 25 10:22:48 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Mon, 25 Aug 2014 22:52:48 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this, 73s, Abhi On Monday, August 25, 2014, k3it wrote: > Is there an easy way to identify which radios need a correction for 10/12m > coils? > > Vasiliy > > > On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO > wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> >> >> Excuse me. A more accurate statement would?ve been: >> >> "The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience a lower maximum output power on 10m than you will if the >> windings are correct.? >> >> 73, Joe K5SO >> >> >> On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: >> >> > ***** High Performance Software Defined Radio Discussion List ***** >> > >> > Hi Brian, >> > >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> > >> > The firmware uses correct switch-point frequencies for the Alex filter >> set, which is also the correct switch-point frequencies for the ANAN-series >> radios that have the correct windings on their filters. It is my >> understanding that later versions of the ANAN series radios use correct >> windings on their 10/12m filters so their switch points should be identical >> to those in Alex. Earlier versions of the ANAN series radios do not. >> > >> > The firmware ?patch? used initially by Abhi to correct the 10m low >> power output for some ANAN series radios is not the ideal method for >> correcting the issue of low power output on 10m on those earlier ANAN >> radios, as the issue is actually a hardware issue, not a firmware or >> software issue. If Abhi wishes to create a version of firmware that uses >> different switch points from Alex that?s his prerogative but you should be >> aware that the issue is not actually a firmware issue, it?s a hardware >> issue. >> > >> > The fact is that there should be only a single firmware version to use >> with each of the Hermes, Angelia, and Orion boards, respectively, >> regardless of whether the board are used in an ANAN-series configuration >> with the Apache Labs filters or in a stand alone configuration using Alex >> filters. The "correct fix? for ANAN radios that have the low power output >> issue on 10m is to rewind the filter toroids for the 10/12 m filters on >> those radios, not to patch the firmware or software to use switch points >> that are different from the Alex filter design. >> > >> > >> > 73, Joe K5SO >> > >> > On Aug 24, 2014, at 6:38 AM, Brian D wrote: >> > >> >> Joe Martin K5SO > > wrote: >> >> >> >>> ***** High Performance Software Defined Radio Discussion List ***** >> >>> >> >>> All, >> >>> >> >>> Angelia_v4.2 firmware is available for download from >> >>> >> >>> http://k5so.com/HPSDR_downloads.html >> >>> >> >> Is this suitable for use in the ANAN range of tranceivers or does it >> need to >> >> be changed by Abhi for the different filter frequencies? >> >> >> >> -- >> >> Brian D >> >> G3VGZ >> >> >> >> --- >> >> This email is free from viruses and malware because avast! Antivirus >> protection is active. >> >> http://www.avast.com >> >> >> > >> > _______________________________________________ >> > HPSDR Discussion List >> > To post msg: hpsdr at openhpsdr.org >> >> > Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> > HPSDR web page: http://openhpsdr.org >> > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjablonski at att.net Mon Aug 25 10:31:25 2014 From: bjablonski at att.net (Barry Jablonski) Date: Mon, 25 Aug 2014 13:31:25 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53FB72ED.8060107@att.net> Thanks for that information Dave. I'm mainly interested in the Hermes FPGA code and this will save me time. I also just found out I will have to downgrade Quartus II from v14 to v13.1 since the latest version has dropped support for Cyclone III devices. Barry WB2ZXJ From mstangelo at comcast.net Mon Aug 25 12:49:23 2014 From: mstangelo at comcast.net (mstangelo at comcast.net) Date: Mon, 25 Aug 2014 19:49:23 +0000 (UTC) Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> Abhi, You responded with: "Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this," You also had an issue low power with 12M. Do we need your special code to switcg in different LP filters for the 12 Meter band? Mike N2MS ----- Original Message ----- From: Abhi A To: k3it Cc: HPSDR list Sent: Mon, 25 Aug 2014 17:22:48 -0000 (UTC) Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** From gregg.w6izt1 at gmail.com Mon Aug 25 12:55:49 2014 From: gregg.w6izt1 at gmail.com (Gregg W6IZT) Date: Mon, 25 Aug 2014 15:55:49 -0400 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> References: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> Message-ID: <047601cfc09e$91ea2240$b5be66c0$@gmail.com> I had the low power issue on 12 m and a change to the FW resolved it. I'd prefer to address a HW problem in HW by adjusting the inductors in the LPF to have the correct number of turns. I now have that information on the correct number of turns for the inductors in question. Question: Will I need to change the FW if I correct the inductors? Gregg W6IZT -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of mstangelo at comcast.net Sent: Monday, August 25, 2014 3:49 PM To: Abhi A Cc: HPSDR list Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** Abhi, You responded with: "Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this," You also had an issue low power with 12M. Do we need your special code to switcg in different LP filters for the 12 Meter band? Mike N2MS ----- Original Message ----- From: Abhi A To: k3it Cc: HPSDR list Sent: Mon, 25 Aug 2014 17:22:48 -0000 (UTC) Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From ka6tya at arrl.net Mon Aug 25 13:22:35 2014 From: ka6tya at arrl.net (Pat McGrath) Date: Mon, 25 Aug 2014 13:22:35 -0700 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: <047601cfc09e$91ea2240$b5be66c0$@gmail.com> References: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> <047601cfc09e$91ea2240$b5be66c0$@gmail.com> Message-ID: <000301cfc0a2$4ed683f0$ec838bd0$@arrl.net> Abhi A Will your company permanently fix the problem? -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Gregg W6IZT Sent: Monday, August 25, 2014 12:56 PM To: mstangelo at comcast.net; 'Abhi A' Cc: 'HPSDR list' Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** I had the low power issue on 12 m and a change to the FW resolved it. I'd prefer to address a HW problem in HW by adjusting the inductors in the LPF to have the correct number of turns. I now have that information on the correct number of turns for the inductors in question. Question: Will I need to change the FW if I correct the inductors? Gregg W6IZT -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of mstangelo at comcast.net Sent: Monday, August 25, 2014 3:49 PM To: Abhi A Cc: HPSDR list Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** Abhi, You responded with: "Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this," You also had an issue low power with 12M. Do we need your special code to switcg in different LP filters for the 12 Meter band? Mike N2MS ----- Original Message ----- From: Abhi A To: k3it Cc: HPSDR list Sent: Mon, 25 Aug 2014 17:22:48 -0000 (UTC) Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From abhiarunoday at gmail.com Mon Aug 25 20:46:58 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Tue, 26 Aug 2014 09:16:58 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) Message-ID: Hi Guys, I think there is some confusion here, all ANAN radios use the 17/15M LPF on 12M as well, changing the coils on the 10M LPF does not effect the 12M output, The change in the 10M LPF was to prevent low output on the 10M band in some radios, if you are not experiencing low power on 10M this does not effect you, The Orion and Angelia firmware already have this change coded in, the Original Hermes firmware does not, hence, Apache releases a B version which incorporates this change, 73s, Abhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Mon Aug 25 21:53:53 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Mon, 25 Aug 2014 23:53:53 -0500 Subject: [hpsdr] Fwd: RE: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: Is it just me or does the fwd pwr TX meter seem to be to be reading lower than it should with this release? I was checking power outputs and it seems to be about 15 watts lower than reality. Is this just me? I was trying to adjust output power and that's when I realized it. I reset databases just to be sure. I didn't notice this on 3.2.17. 73, Jae - K5JAE -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhiarunoday at gmail.com Mon Aug 25 22:38:55 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Tue, 26 Aug 2014 11:08:55 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) Message-ID: Further update and correction: The 10M Coil update also fixes the 12M low power output, however, using the 17/15M LPF for 12M also works, The current Orion firmware uses the 10M LPF for 12M, all 200Ds shipped have the LPF change incorporated, The Angelia and Hermes (B) Firmware uses the 17/15M LPF for 12M, I believe all radios shipped from March 2014 as Joe indicated have this change incorporated, In case you are experiencing low output on 12/10M please contact Apache Support and we will be happy to assist in resolving this issue, 73s, Abhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian13434 at yahoo.co.uk Tue Aug 26 02:54:53 2014 From: brian13434 at yahoo.co.uk (Brian D) Date: Tue, 26 Aug 2014 10:54:53 +0100 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: Jae Stutzman wrote: > Is it just me or does the fwd pwr TX meter seem to be to be reading lower > than it should with this release? I was checking power outputs and it > seems to be about 15 watts lower than reality. Is this just me? I was > trying to adjust output power and that's when I realized it. I reset > databases just to be sure. I didn't notice this on 3.2.17. I haven't noticed it reading low but I've had several times it reading NaN for VSWR when tuning into the goood match of my test load. Not sure at this stage if it is the new version of HPSDR or my recent firmware upgrade to 4.2 (angelia). -- Brian D G3VGZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From k5jae at stutzman.net Tue Aug 26 05:38:52 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Tue, 26 Aug 2014 07:38:52 -0500 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: I should have mentioned that I recently upgraded to 4.2 Angelia as well. So it could be either. I'll try downgrading back to 4.1 to see if that changes anything. I noticed it with TUN and it was reading out about 85W for each band. I was originally trying to find out if I was affected by the 10M winding issue. On Tue, Aug 26, 2014 at 4:54 AM, Brian D wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Jae Stutzman wrote: > > > Is it just me or does the fwd pwr TX meter seem to be to be reading lower > > than it should with this release? I was checking power outputs and it > > seems to be about 15 watts lower than reality. Is this just me? I was > > trying to adjust output power and that's when I realized it. I reset > > databases just to be sure. I didn't notice this on 3.2.17. > > I haven't noticed it reading low but I've had several times it reading NaN > for VSWR when tuning into the goood match of my test load. Not sure at this > stage if it is the new version of HPSDR or my recent firmware upgrade to > 4.2 > (angelia). > > > -- > Brian D > G3VGZ > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernd.gasser at tele2.at Tue Aug 26 06:01:36 2014 From: bernd.gasser at tele2.at (Bernd Gasser) Date: Tue, 26 Aug 2014 15:01:36 +0200 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <008001cfc12d$dea6b4b0$9bf41e10$@tele2.at> Hi Hermann et al, after seeing all your interesting messages I was also infected by the cuda-virus and ordered a Jetson TK1 to play with. So far I managed to set it up with Qt5.4 and cuda-6.0 installed and I have successfully compiled cuSDR64 and ghpsdr-alex on it which both seems to run fine with a little high CPU-load. (cuSDR64 shows abt 155%). When looking at the shared libraries mapped to the running binary I noticed it is still using the 'standard libfftw3' library instead of the ones optimized for the TEGRA 192 GPU cores supplied with cuda-6.0. UID PID PPID C STIME TTY TIME CMD ubuntu 2942 2607 99 12:07 pts/4 00:38:25 ./cuSDR64 ubuntu at tegra-ubuntu:/proc/2942$ grep fftw maps b6665000-b67ad000 r-xp 00000000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 b67ad000-b67b4000 ---p 00148000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 b67b4000-b67bc000 r--p 00147000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 b67bc000-b67bd000 rw-p 0014f000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 What would be the required change in the build environment to make use of the cuda-6.0 libraries in /usr/local/cuda-6.0/lib/libcufftw* ? - Has anyone done this yet and could give me some pointers? tnx & 73, Bernd/OE1ACM -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von Hermann Gesendet: Montag, 18. August 2014 13:24 An: Chris Smith; hpsdr at lists.openhpsdr.org Betreff: Re: [hpsdr] 20140126cuSDR64 & TK1 ***** High Performance Software Defined Radio Discussion List ***** From gokoyev+k3it at gmail.com Tue Aug 26 06:23:48 2014 From: gokoyev+k3it at gmail.com (k3it) Date: Tue, 26 Aug 2014 09:23:48 -0400 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <008001cfc12d$dea6b4b0$9bf41e10$@tele2.at> References: <20140817163704.A6AAD48278@diego.dreamhost.com> <008001cfc12d$dea6b4b0$9bf41e10$@tele2.at> Message-ID: Here is a link that describes what needs to be done to convert to cufftw http://docs.nvidia.com/cuda/cufft/index.html#fftw-supported-interface But this looks too easy to be true :) I haven't tried it. Also running Jetson board here with gphpsdr3 73 Vasiliy On Tue, Aug 26, 2014 at 9:01 AM, Bernd Gasser wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Hermann et al, > after seeing all your interesting messages I was also infected by the > cuda-virus and ordered a Jetson TK1 to play with. > > So far I managed to set it up with Qt5.4 and cuda-6.0 installed and I have > successfully compiled cuSDR64 and ghpsdr-alex on it which both seems to run > fine with a little high CPU-load. (cuSDR64 shows abt 155%). > > When looking at the shared libraries mapped to the running binary I noticed > it is still using the 'standard libfftw3' library instead of the ones > optimized for the TEGRA 192 GPU cores supplied with cuda-6.0. > > > UID PID PPID C STIME TTY TIME CMD > ubuntu 2942 2607 99 12:07 pts/4 00:38:25 ./cuSDR64 > > ubuntu at tegra-ubuntu:/proc/2942$ grep fftw maps > b6665000-b67ad000 r-xp 00000000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > b67ad000-b67b4000 ---p 00148000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > b67b4000-b67bc000 r--p 00147000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > b67bc000-b67bd000 rw-p 0014f000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > > What would be the required change in the build environment to make use of > the cuda-6.0 libraries in /usr/local/cuda-6.0/lib/libcufftw* ? - Has > anyone > done this yet and could give me some pointers? > > tnx & 73, > Bernd/OE1ACM > > > > > > > > -----Urspr?ngliche Nachricht----- > Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von > Hermann > Gesendet: Montag, 18. August 2014 13:24 > An: Chris Smith; hpsdr at lists.openhpsdr.org > Betreff: Re: [hpsdr] 20140126cuSDR64 & TK1 > > ***** High Performance Software Defined Radio Discussion List ***** > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnlaur at gmail.com Tue Aug 26 08:08:04 2014 From: johnlaur at gmail.com (John Laur) Date: Tue, 26 Aug 2014 10:08:04 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: Ideas for discussion: First, isn't this similar to the architecture that has been implemented by PA3FWM's wideband websdr for some time? ADC->FPGA->Ethernet->FFT with GPU and then individual receivers only have to grab the bins and do an IFFT? If so, it's a clear winner as far as scaling the capabilities go. I am very excited to see the excitement for it. But I am concerned with the discussion dwelling around the Jetson board as being central and essential to this architecture long-term although I do think it is valuable as a motivator. For a hardware architecture that will hang around for a while and be the most compatible, I would like to discuss the option of designing instead for regular (non-mini) PCI-e. While it's great to have these 'fun-size' SBC's there is really nothing that I have seen to conclude that NVidia or a 3rd party will continue to ship such a thing as a developer or retail product with extremely similar architecture and form factor over the long term. So unless there is someone who wants to keep up with the hassle of actually integrating NVidia silicon onto an HPSDR board and making a wholly integrated system a la the Flex-6k, I do not think it is worth exploring too far into that paradigm. Designing for the Jetson's mini-pcie interface would severely limit future flexibility should the product be dropped and limit the use of the HPSDR hardware in cases where mini-pcie is not available on a board with a suitable CUDA GPU. Plus, Jetson itself has a huge disadvantage (for the HPSDR server application) of having only a single Ethernet interface. I understand that there is still 16Mbps of bandwidth 'left over' (and that the interface itself is full duplex) but that is an awfully limiting margin considering the possibilities that exist with the architecture. Yes; one could be added on USB without occupying the mini-PCIe, but at the expense of the limited CPU resources. Running ethernet interfaces at 99% capacity is a tricky business anyway. It would be nice to simply eliminate that challenge. There is one thing we can be sure of though: NVidia will continue to ship regular PCI-e graphics cards for the foreseeable future. Depending on the version of CUDA required, an inexpensive NVidia GeForce card will likely exceed Jetson's performance by quite a lot. A small dedicated system with dual PCIe slots and a GPU can be designed and built with specifications exceeding those of the Jetson board at similar cost, and the same architecture can be implemented. I do not see that the Jetson has any advantage over such system other than perhaps power consumption or having fixed design. The problem of power consumption is likely not to be a large concern in this application, and the second problem can be eliminated by specifying a tested reference design. * PCI-e is the fastest common interface available. Current standards take speeds to 250gbps (PCI-e 4.0 x16), and even the lowest common denominator (PCI-e 1.0 1x) is still 2gbps. * PCI-e can be bridged to Mini-PCIe, Thunderbolt, or Expresscard interfaces with off-the-shelf hardware. * PCI-e supports DMA, RDMA, and peer to peer data transfer. Data can be moved from HPDSR to GPU without involving the CPU. A passive PCI-e backplane could be used as a future replacement for Atlas with the ability to use off the shelf parts. * PCI-e is easy to interface in the modern Altera FPGAs with hardware controllers and does not require the difficult task of writing IP for 3rd party interface chips (Existing IP for things like USB 3.0 controllers and 10gbE chips are licensed and generally not compatible with open-source licenses. I believe this is one of the major pain points with the current HPSDR FPGA efforts.) * PCI-e is generally backwards (and forwards!) compatible. So modern high-bandwidth hardware can be designed and still used with older or less powerful hosts. An external interface of some sort has the advantage that the RF bits can be somewhat isolated from the noisy computer bits, but there are ways to mitigate that and still use PCI-e, such as using a case design that ensures the RF side is well shielded. The design could also be broken into two parts with the ADC/DAC/Clocks isolated and connected to the FPGA on a PCI-e card by means of line driver ICs and off-the-shelf cables. Any thoughts from those more involved with the software or hardware design? 73, John KF5SAB On Fri, Aug 22, 2014 at 10:31 PM, Phil Harman wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Marc, > > Thanks for your email. > > We still have a way to go with fully proving the DFC idea but so far its looking good. > > We actually had this discussion a few minutes ago during the weekly Teamspeak session. > > Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. > > What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. > > What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. > > With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. > > If such a PCB design is of interest to you then please lets discuss further. > > 73 Phil....VK6PH > > > -----Original Message----- From: Marc Lalonde > Sent: Saturday, August 23, 2014 10:31 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > guess some one already work on a ADC /DAC Board that go on the expansion > connector of the DEV kit ? > seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA > as Glue logic.. > > that may remove the LAN / PHY from equation and permit made nice self > contained platform ;-) > > if no one yet ,i may willing to help work on this ,i was a senior PCB > designer whit some design backgrond .. > > Best 73! > Marc VE2OLM From k5so at valornet.com Tue Aug 26 09:35:24 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Tue, 26 Aug 2014 10:35:24 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <3AD73732-607A-4AB5-96C3-5B78FB0B1477@valornet.com> Hi John, I completely agree with your analysis and have in fact privately expressed to several people my concern regarding use of a (marginally powerful) single board computer in the mix. But keep in mind that the new protocol that Phil is contemplating will work fine with either a single powerful computer (SBC) connected to the hardware OR with a high performance computer connected to the hardware as we have traditionally done. Therefore the SBC development activity underway doesn?t limit things at all for those of us who would prefer to use a single high performance computer instead. Users of a single high performance computer can still exploit the new protocol and realize the same flexibility and performance benefits that Phil mentioned that are associated with the new proposed ethernet protocol. The Jetson board SBC approach is simply an activity that is running in parallel with the original architecture scheme. Whether you wish to use an SBC configuration or not is entirely optional and open to your personal preference. I?ve come to realize that we?re not losing anything at all by having some people working on SBC configurations in order to have low-performance hand held devices able to interface the hardware (if that happens to be your personal interest). 73, Joe K5SO From dc6ny at gmx.de Tue Aug 26 09:36:24 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Tue, 26 Aug 2014 18:36:24 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <000001cfc14b$e0b5c2f0$a22148d0$@de> Nice reasoning, John. Thanks. 73, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von John Laur Gesendet: Dienstag, 26. August 2014 17:08 An: HPSDR list Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Ideas for discussion: First, isn't this similar to the architecture that has been implemented by PA3FWM's wideband websdr for some time? ADC->FPGA->Ethernet->FFT with GPU and then individual receivers only have to grab the bins and do an IFFT? If so, it's a clear winner as far as scaling the capabilities go. I am very excited to see the excitement for it. But I am concerned with the discussion dwelling around the Jetson board as being central and essential to this architecture long-term although I do think it is valuable as a motivator. For a hardware architecture that will hang around for a while and be the most compatible, I would like to discuss the option of designing instead for regular (non-mini) PCI-e. While it's great to have these 'fun-size' SBC's there is really nothing that I have seen to conclude that NVidia or a 3rd party will continue to ship such a thing as a developer or retail product with extremely similar architecture and form factor over the long term. So unless there is someone who wants to keep up with the hassle of actually integrating NVidia silicon onto an HPSDR board and making a wholly integrated system a la the Flex-6k, I do not think it is worth exploring too far into that paradigm. Designing for the Jetson's mini-pcie interface would severely limit future flexibility should the product be dropped and limit the use of the HPSDR hardware in cases where mini-pcie is not available on a board with a suitable CUDA GPU. Plus, Jetson itself has a huge disadvantage (for the HPSDR server application) of having only a single Ethernet interface. I understand that there is still 16Mbps of bandwidth 'left over' (and that the interface itself is full duplex) but that is an awfully limiting margin considering the possibilities that exist with the architecture. Yes; one could be added on USB without occupying the mini-PCIe, but at the expense of the limited CPU resources. Running ethernet interfaces at 99% capacity is a tricky business anyway. It would be nice to simply eliminate that challenge. There is one thing we can be sure of though: NVidia will continue to ship regular PCI-e graphics cards for the foreseeable future. Depending on the version of CUDA required, an inexpensive NVidia GeForce card will likely exceed Jetson's performance by quite a lot. A small dedicated system with dual PCIe slots and a GPU can be designed and built with specifications exceeding those of the Jetson board at similar cost, and the same architecture can be implemented. I do not see that the Jetson has any advantage over such system other than perhaps power consumption or having fixed design. The problem of power consumption is likely not to be a large concern in this application, and the second problem can be eliminated by specifying a tested reference design. * PCI-e is the fastest common interface available. Current standards take speeds to 250gbps (PCI-e 4.0 x16), and even the lowest common denominator (PCI-e 1.0 1x) is still 2gbps. * PCI-e can be bridged to Mini-PCIe, Thunderbolt, or Expresscard interfaces with off-the-shelf hardware. * PCI-e supports DMA, RDMA, and peer to peer data transfer. Data can be moved from HPDSR to GPU without involving the CPU. A passive PCI-e backplane could be used as a future replacement for Atlas with the ability to use off the shelf parts. * PCI-e is easy to interface in the modern Altera FPGAs with hardware controllers and does not require the difficult task of writing IP for 3rd party interface chips (Existing IP for things like USB 3.0 controllers and 10gbE chips are licensed and generally not compatible with open-source licenses. I believe this is one of the major pain points with the current HPSDR FPGA efforts.) * PCI-e is generally backwards (and forwards!) compatible. So modern high-bandwidth hardware can be designed and still used with older or less powerful hosts. An external interface of some sort has the advantage that the RF bits can be somewhat isolated from the noisy computer bits, but there are ways to mitigate that and still use PCI-e, such as using a case design that ensures the RF side is well shielded. The design could also be broken into two parts with the ADC/DAC/Clocks isolated and connected to the FPGA on a PCI-e card by means of line driver ICs and off-the-shelf cables. Any thoughts from those more involved with the software or hardware design? 73, John KF5SAB On Fri, Aug 22, 2014 at 10:31 PM, Phil Harman wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Marc, > > Thanks for your email. > > We still have a way to go with fully proving the DFC idea but so far its looking good. > > We actually had this discussion a few minutes ago during the weekly Teamspeak session. > > Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. > > What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. > > What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. > > With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. > > If such a PCB design is of interest to you then please lets discuss further. > > 73 Phil....VK6PH > > > -----Original Message----- From: Marc Lalonde > Sent: Saturday, August 23, 2014 10:31 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > guess some one already work on a ADC /DAC Board that go on the > expansion connector of the DEV kit ? > seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA > as Glue logic.. > > that may remove the LAN / PHY from equation and permit made nice self > contained platform ;-) > > if no one yet ,i may willing to help work on this ,i was a senior > PCB designer whit some design backgrond .. > > Best 73! > Marc VE2OLM _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From k5so at valornet.com Tue Aug 26 09:38:47 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Tue, 26 Aug 2014 10:38:47 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <3AD73732-607A-4AB5-96C3-5B78FB0B1477@valornet.com> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> <3AD73732-607A-4AB5-96C3-5B78FB0B1477@valornet.com> Message-ID: > ... will work fine with either a single powerful computer (SBC) connected to the hardware OR with a high performance computer connected to the hardware as we have traditionally done. I meant: single board computer (SBC). 73, Joe K5SO On Aug 26, 2014, at 10:35 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi John, > > I completely agree with your analysis and have in fact privately expressed to several people my concern regarding use of a (marginally powerful) single board computer in the mix. But keep in mind that the new protocol that Phil is contemplating will work fine with either a single powerful computer (SBC) connected to the hardware OR with a high performance computer connected to the hardware as we have traditionally done. > > Therefore the SBC development activity underway doesn?t limit things at all for those of us who would prefer to use a single high performance computer instead. Users of a single high performance computer can still exploit the new protocol and realize the same flexibility and performance benefits that Phil mentioned that are associated with the new proposed ethernet protocol. > > The Jetson board SBC approach is simply an activity that is running in parallel with the original architecture scheme. Whether you wish to use an SBC configuration or not is entirely optional and open to your personal preference. I?ve come to realize that we?re not losing anything at all by having some people working on SBC configurations in order to have low-performance hand held devices able to interface the hardware (if that happens to be your personal interest). > > 73, Joe K5SO > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlalonde at alphatronique.com Tue Aug 26 09:43:08 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Tue, 26 Aug 2014 12:43:08 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <53FCB91C.1090209@alphatronique.com> HI mini-PCI-e may put on PCI-e whit common adapter ,then put on standard PC if need or may use PCI-e to PCI-e backplane + CPU of some sort ,so many possibility it need at last 2 lane for a decent SDR (make cation whit Bit Vs Byte) ADC was 12 Bit x 122Mhx and DAC was 14 bit x 122Mhz this may also double in future... so ~ 3.2Gbit/s integrating NVidia silicon onto an HPSDR ,not a thing that i doable at decent cost Best 73! Marc L. VE2OLM On 26/08/2014 11:08 AM, John Laur wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Ideas for discussion: > > First, isn't this similar to the architecture that has been > implemented by PA3FWM's wideband websdr for some time? > ADC->FPGA->Ethernet->FFT with GPU and then individual receivers only > have to grab the bins and do an IFFT? If so, it's a clear winner as > far as scaling the capabilities go. I am very excited to see the > excitement for it. But I am concerned with the discussion dwelling > around the Jetson board as being central and essential to this > architecture long-term although I do think it is valuable as a > motivator. > > For a hardware architecture that will hang around for a while and be > the most compatible, I would like to discuss the option of designing > instead for regular (non-mini) PCI-e. > > While it's great to have these 'fun-size' SBC's there is really > nothing that I have seen to conclude that NVidia or a 3rd party will > continue to ship such a thing as a developer or retail product with > extremely similar architecture and form factor over the long term. So > unless there is someone who wants to keep up with the hassle of > actually integrating NVidia silicon onto an HPSDR board and making a > wholly integrated system a la the Flex-6k, I do not think it is worth > exploring too far into that paradigm. Designing for the Jetson's > mini-pcie interface would severely limit future flexibility should the > product be dropped and limit the use of the HPSDR hardware in cases > where mini-pcie is not available on a board with a suitable CUDA GPU. > Plus, Jetson itself has a huge disadvantage (for the HPSDR server > application) of having only a single Ethernet interface. I understand > that there is still 16Mbps of bandwidth 'left over' (and that the > interface itself is full duplex) but that is an awfully limiting > margin considering the possibilities that exist with the architecture. > Yes; one could be added on USB without occupying the mini-PCIe, but at > the expense of the limited CPU resources. Running ethernet interfaces > at 99% capacity is a tricky business anyway. It would be nice to > simply eliminate that challenge. > > There is one thing we can be sure of though: NVidia will continue to > ship regular PCI-e graphics cards for the foreseeable future. > Depending on the version of CUDA required, an inexpensive NVidia > GeForce card will likely exceed Jetson's performance by quite a lot. A > small dedicated system with dual PCIe slots and a GPU can be designed > and built with specifications exceeding those of the Jetson board at > similar cost, and the same architecture can be implemented. I do not > see that the Jetson has any advantage over such system other than > perhaps power consumption or having fixed design. The problem of power > consumption is likely not to be a large concern in this application, > and the second problem can be eliminated by specifying a tested > reference design. > > * PCI-e is the fastest common interface available. Current standards > take speeds to 250gbps (PCI-e 4.0 x16), and even the lowest common > denominator (PCI-e 1.0 1x) is still 2gbps. > > * PCI-e can be bridged to Mini-PCIe, Thunderbolt, or Expresscard > interfaces with off-the-shelf hardware. > > * PCI-e supports DMA, RDMA, and peer to peer data transfer. Data can > be moved from HPDSR to GPU without involving the CPU. A passive PCI-e > backplane could be used as a future replacement for Atlas with the > ability to use off the shelf parts. > > * PCI-e is easy to interface in the modern Altera FPGAs with hardware > controllers and does not require the difficult task of writing IP for > 3rd party interface chips (Existing IP for things like USB 3.0 > controllers and 10gbE chips are licensed and generally not compatible > with open-source licenses. I believe this is one of the major pain > points with the current HPSDR FPGA efforts.) > > * PCI-e is generally backwards (and forwards!) compatible. So modern > high-bandwidth hardware can be designed and still used with older or > less powerful hosts. > > An external interface of some sort has the advantage that the RF bits > can be somewhat isolated from the noisy computer bits, but there are > ways to mitigate that and still use PCI-e, such as using a case design > that ensures the RF side is well shielded. The design could also be > broken into two parts with the ADC/DAC/Clocks isolated and connected > to the FPGA on a PCI-e card by means of line driver ICs and > off-the-shelf cables. > > Any thoughts from those more involved with the software or hardware design? > > 73, John KF5SAB > > > On Fri, Aug 22, 2014 at 10:31 PM, Phil Harman wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Marc, >> >> Thanks for your email. >> >> We still have a way to go with fully proving the DFC idea but so far its looking good. >> >> We actually had this discussion a few minutes ago during the weekly Teamspeak session. >> >> Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. >> >> What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. >> >> What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. >> >> With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. >> >> If such a PCB design is of interest to you then please lets discuss further. >> >> 73 Phil....VK6PH >> >> >> -----Original Message----- From: Marc Lalonde >> Sent: Saturday, August 23, 2014 10:31 AM >> To: hpsdr at lists.openhpsdr.org >> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >> >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi >> >> guess some one already work on a ADC /DAC Board that go on the expansion >> connector of the DEV kit ? >> seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA >> as Glue logic.. >> >> that may remove the LAN / PHY from equation and permit made nice self >> contained platform ;-) >> >> if no one yet ,i may willing to help work on this ,i was a senior PCB >> designer whit some design backgrond .. >> >> Best 73! >> Marc VE2OLM > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From hvh.net at gmail.com Tue Aug 26 10:40:02 2014 From: hvh.net at gmail.com (Hermann) Date: Tue, 26 Aug 2014 19:40:02 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: Dear John, all, thank you all for your thoughts. Here's my 2-cent: the discussion focus too much on Hardware, and the Jetson board is surely an experimental platform. It doesn't makes much sense to ponder upon if this board has one or two ethernet interfaces. Of course, this does matter if a certain architecture should be tested. Btw, the upcoming Tablets and Handhelds will have chips like the Tegra K1, and in a couple of years even more powerful devices. So, we will indeed have handhelds with super-computing power - at least in a certain sense. Hardware is subject to fast changes, but how do we keep up with the Software? Why do you think is Altera, e.g., providing an interface to OpenCL? Nvidia is doing a really great job in providing not only fast hardware, but also a complete programming model, together with all necessary tools. In a completely different domain (but also embedded), chip providers are building great hardware, with 6 or more cores etc etc., but don't tell the software architects how to program these fine controllers, or how to migrate software, which grew out of 20 years of development (and as such is invaluable). The 'multicore problem' is still not solved (some may claim they have), and the majority of algorithms and code (with some very few exceptions, like FFTs, or matrix multiplication) is NOT easily parallelized. Why does nobody (with very few but remarkable exceptions) take existing code (KISS Console, PowerSDR, cuSDR) and work on it to implement this or that feature? I receive so many emails and comments on the mailing lists, asking for new features. And if it's not going fast enough, people start declaring cuSDR as vaporware, hi. It is not much more difficult, than, as Joe, K5SO has reported so wonderful, start working on code for FPGAs. Hardware changes fast, Software not. The idea of open source is not only that the software is free. Much more important is that a lot of people start contributing to it. For me this is the main message from Phil's original post. 73, Hermann DL3HVH -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcrewson at cinci.rr.com Tue Aug 26 11:45:42 2014 From: rcrewson at cinci.rr.com (Rob Crewson) Date: Tue, 26 Aug 2014 14:45:42 -0400 Subject: [hpsdr] 'Cuda 6.5 Features and OverView'. Message-ID: <000c01cfc15d$f0843830$d18ca890$@cinci.rr.com> To anyone interested in this topic. I just watched a webinar from NVidia on their recent release of Cuda 6.5 -> 'Cuda 6.5 Features and OverView'. I took screenshots of the presentation slides (14) . The last one is of the chat board questions, one which pertained to the 'Jetson tk1' board. If you want a copy of either email me off list @ rcrewson at cinci.rr.com . 73, RobC VE3EW -------------- next part -------------- An HTML attachment was scrubbed... URL: From jra at febo.com Tue Aug 26 12:16:43 2014 From: jra at febo.com (John Ackermann N8UR) Date: Tue, 26 Aug 2014 15:16:43 -0400 Subject: [hpsdr] External T/R switch for PureSignal Message-ID: <53FCDD1B.5010803@febo.com> If you're interested in a kit to provide external T/R switching optimized for PureSignal setups, read on. If you've experimented with PureSignal, you know that the ANAN T/R switching isn't up to the task because (a) it shorts the receiver input to ground during TX, and (b) there is a lot of crosstalk within the switch/filter board. The combination means that you can't get a useful sampler signal into the radio without some sort of modification. Thanks to much help from KC9XG, I found that it's easy on the ANAN-10 to bypass the internal T/R by just removing the RX coax between the Hermes board and the amp board. Then, you can use the Hermes SMA RX connector and get TX from the ANT1 BNC connector. After that, all you need is an external switch. No new holes are required. (I don't own an ANAN-100 but as long as you can route the RX signal directly to the Hermes receive input, the same setup should work.) The external switch needs two relays: one to switch the antenna between TX and RX, and the second to switch the receiver path between antenna on RX and a signal sampler on TX. It needs good isolation for PureSignal (which is where my perfboard prototype with junkbox relays fell short). So, I've laid out a 3 inch (wide) by 1 inch (deep) circuit board with two BNC connectors (ANT and TX) and two SMA connectors (RX and SAMPLE). It uses the same relays as the Alex boards, and theoretically should have more than enough isolation for PureSignal. It should handle 100W. It takes 12V input and has a transistor switch for keying. This is early stage, and I'm just ordering Rev. A boards now. But I'm trying to see if there's enough interest to do a TAPR kit (all through-hole parts!) that would probably be in the $50 range. If you'd be interested, please drop a note off-list to jra at febo.com. 73, John From jbden at charter.net Tue Aug 26 12:47:31 2014 From: jbden at charter.net (John) Date: Tue, 26 Aug 2014 14:47:31 -0500 Subject: [hpsdr] AsRock SBC Message-ID: <53FCE453.8030503@charter.net> If some one is looking for a nice SBC, check out AsRock's line of j1900 mini-itx motherboards. I just buit one using memory and case I had on hand, for less than $200. It has built in dc-dc converter so it will use a netbook brick for power. Only uses about 10 Watts. Soon after I built it, they announced a new one using j2900 intel Pentium. I am not going to list all features, because they are on Asrock's site. John N4HXL From k5so at valornet.com Tue Aug 26 12:59:31 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Tue, 26 Aug 2014 13:59:31 -0600 Subject: [hpsdr] Timing Closure Field Guide Message-ID: All, In an effort to assist in making the timing closure tasks associated with OpenHPSDR firmware development less intimidating and easier for beginners to participate I have prepared a PDF document that describes a standardized procedure that I use for the task. The document may be downloaded from http://www.k5so.com/TimingClosureFieldGuide.pdf Please be aware that I do not claim to be an expert in this area and that the document may well have some errors and omissions; but I can guarantee that the document contains a decent sampling of the author?s personal bias. 73, Joe K5SO -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnlaur at gmail.com Tue Aug 26 13:27:22 2014 From: johnlaur at gmail.com (John Laur) Date: Tue, 26 Aug 2014 15:27:22 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53FCB91C.1090209@alphatronique.com> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> <53FCB91C.1090209@alphatronique.com> Message-ID: All, Thank you for the good discussion. My intention was not to focus too much on the Jetson discussion actually; I do know that if the code runs on Jetson I can happily build a small linux machine that will also run it, so nobody is "locking" anyone into any particular thing. I just think the Jetson is a low mark to aim for. If it can do a realtime 30mHz FFT, so can basically any current GPU. Even low power cards like the GeForce 750 Ti will run circles around it, while drawing 60W and costing less. I think anyone who has ever compiled up the fosphor plugin on GNU Radio has probably lamented not having that view available all the time. So I wont beat on Jetson any more. I just thought while we were on the subject of architectures it would be a good time to cut to the chase on the bandwidth problem. While I will agree with Hermann that SDR hardware (and the HDL features of HPSDR) seem to be changing as fast or faster than SDR software in recent months, I also think it ought to be the other way around. On the big list of SDR's from Wikipedia http://en.wikipedia.org/wiki/List_of_software-defined_radios I note only 2 devices use PCIe. I think the hardware is changing largely because of all the ways that developers are choosing to deal with the problems of interface constraints; hardware that can filter this amount of data at this datarate is neither easy nor cheap to engineer. There is no need to go to this length if you can just move all the data in the first place. But if the GPU architecture is the way forward, it's just silly to put an intermediate interface that requires a lot of HDL work in the way. For a direct sampling design the most future proof design possible is to make sure the hardware is at minimum capable of sending the raw ADC/DAC/Clock data in and out at full datarate to an attached device. IMO the reason working with the SoCKit hardware and Scotty's boards is probably so nice is because the interface from the FPGA to the software is basically transparent. (This is half speculation as I have a SoCKit that I have used quite a bit but have not yet put funds together for a board set from Scotty) There is no ethernet PHY and framing and protocol to get at the DDC data; the CPU just opens a device and starts reading. If That eliminates a lot of complexity. But you could easily plug his board set into a different dev kit like this http://www.altera.com/products/devkits/altera/kit-cyclone-v-gt.html and with some (admitted) effort you could make yourself a prototype PCIe HPSDR card right now that could do DMA transfers of ADC samples right into GPU memory with the same sort of ease. This is the beauty of a high speed interconnect standard. In this case it is HSMC, useful only within a certain scope, but it makes the point I think. A comment for Marc: From what I have seen Mini-PCIe is generally only ever offered with a x1 interface with the exception of MXM, so it makes more sense to adapt a PCIe card to the mini-PCIe form factor than vice versa; that way the card can be designed as a 4x or such. (It can always be allowed to fall back to 1x) Anyway to sum it all up neatly, a single integrated board like Hermes with a Cyclone V SoC part on board that can be used standalone or plugged in and used as a PCIe card would be pretty attractive HPSDR platform, I gotta say. 73, John KF5SAB From rcrewson at cinci.rr.com Tue Aug 26 15:21:16 2014 From: rcrewson at cinci.rr.com (Rob Crewson) Date: Tue, 26 Aug 2014 18:21:16 -0400 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: <001501cfc17c$0e1ef8d0$2a5cea70$@cinci.rr.com> Excellent document Joe, short , single path , to the point. I've nodded off many time trying to get thru the Altera docs. 73, RobC - VE3EW -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Joe Martin K5SO Sent: Tuesday, August 26, 2014 4:00 PM To: HPSDR list Subject: [hpsdr] Timing Closure Field Guide ***** High Performance Software Defined Radio Discussion List ***** From n9vv at wowway.com Tue Aug 26 15:27:06 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Tue, 26 Aug 2014 17:27:06 -0500 Subject: [hpsdr] AsRock SBC In-Reply-To: <53FCE453.8030503@charter.net> References: <53FCE453.8030503@charter.net> Message-ID: <53FD09BA.30505@wowway.com> Hi John, I also like to point my Update Scanner (checks webpages for chances every day) at this website: http://linuxgizmos.com/category/boards/ LinuxGizmos seems to have quite a wide variety of SBC's listed and updated on an almost hourly basis all the best, 73 de Ken N9VV On 8/26/2014 2:47 PM, John wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > If some one is looking for a nice SBC, check out AsRock's line of j1900 > mini-itx motherboards. > I just buit one using memory and case I had on hand, for less than $200. > It has built in dc-dc converter so it will use a netbook brick for > power. Only uses about 10 Watts. Soon after I built it, they announced a > new one using j2900 intel Pentium. I am not going to list all features, > because they are on Asrock's site. > John N4HXL > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From n9vv at wowway.com Tue Aug 26 15:27:06 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Tue, 26 Aug 2014 17:27:06 -0500 Subject: [hpsdr] AsRock SBC In-Reply-To: <53FCE453.8030503@charter.net> References: <53FCE453.8030503@charter.net> Message-ID: <53FD09BA.30505@wowway.com> Hi John, I also like to point my Update Scanner (checks webpages for chances every day) at this website: http://linuxgizmos.com/category/boards/ LinuxGizmos seems to have quite a wide variety of SBC's listed and updated on an almost hourly basis all the best, 73 de Ken N9VV On 8/26/2014 2:47 PM, John wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > If some one is looking for a nice SBC, check out AsRock's line of j1900 > mini-itx motherboards. > I just buit one using memory and case I had on hand, for less than $200. > It has built in dc-dc converter so it will use a netbook brick for > power. Only uses about 10 Watts. Soon after I built it, they announced a > new one using j2900 intel Pentium. I am not going to list all features, > because they are on Asrock's site. > John N4HXL > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > From scotty at tonks.com Tue Aug 26 16:56:21 2014 From: scotty at tonks.com (Scott Cowling) Date: Tue, 26 Aug 2014 16:56:21 -0700 Subject: [hpsdr] Liva PC on sale at Newegg In-Reply-To: <53FCE453.8030503@charter.net> References: <53FCE453.8030503@charter.net> Message-ID: <7.0.1.0.2.20140826164456.0b4a5008@tonks.com> Hi all, Just saw this on the Newegg site (thanks to Ken, N9VV) and it looks very interesting. http://www.newegg.com/Product/Product.aspx?Item=N82E16856501007 While I have my share of low-power (and low-capability) PCs, this one looks especially intriguing. At only $132 including 2GB of RAM and 32GB eMMC drive, it is about as cheap as they come. Conduction cooled, Gigabit Ethernet, b/g/n WiFi, Bluetooth, dual monitor (HDMI + VGA) support, two USB ports (one 2.0, one 3.0) and a case; what more could you ask for? The special is only good through the end of August, so take a quick look if you are in the market for a new radio toy. Mine arrives Thursday. :-) We'll see if it has the guts to run GHPSDR3-Alex to put an HF1 receiver up on the QtRadio network! 73, Scotty WA2DFI From wb9qzb_groups at yahoo.com Tue Aug 26 17:29:19 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Tue, 26 Aug 2014 17:29:19 -0700 Subject: [hpsdr] Summer 2014 TAPR PSR Digital Communications Journal Available In-Reply-To: <1409098446.44945.YahooMailNeo@web140204.mail.bf1.yahoo.com> References: <1409098446.44945.YahooMailNeo@web140204.mail.bf1.yahoo.com> Message-ID: <1409099359.74958.YahooMailNeo@web140203.mail.bf1.yahoo.com> Summer 2014? TAPR PSR Digital Communications Journal? Available http://www.tapr.org/psr/psr126.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian13434 at yahoo.co.uk Wed Aug 27 02:23:23 2014 From: brian13434 at yahoo.co.uk (Brian D) Date: Wed, 27 Aug 2014 10:23:23 +0100 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: I've reverted to 4.1 firmware. The NaN problem has disappeared so it looks as if the angelia 4.2 firmware is the problem. Jae Stutzman wrote: I should have mentioned that I recently upgraded to 4.2 Angelia as well. So it could be either. I'll try downgrading back to 4.1 to see if that changes anything. I noticed it with TUN and it was reading out about 85W for each band. I was originally trying to find out if I was affected by the 10M winding issue. On Tue, Aug 26, 2014 at 4:54 AM, Brian D wrote: ***** High Performance Software Defined Radio Discussion List ***** Jae Stutzman wrote: > Is it just me or does the fwd pwr TX meter seem to be to be reading lower > than it should with this release? I was checking power outputs and it > seems to be about 15 watts lower than reality. Is this just me? I was > trying to adjust output power and that's when I realized it. I reset > databases just to be sure. I didn't notice this on 3.2.17. I haven't noticed it reading low but I've had several times it reading NaN for VSWR when tuning into the goood match of my test load. Not sure at this stage if it is the new version of HPSDR or my recent firmware upgrade to 4.2 (angelia). -- Brian D G3VGZ -- Brian D G3VGZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From k5so at valornet.com Wed Aug 27 06:10:22 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Wed, 27 Aug 2014 07:10:22 -0600 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: There are unfortunately subtle physical differences board-to-board and chip-to-chip on all of the hardware we use. These differences can sometimes result in different behavior of firmware on some boards. There are no features coded differently in the firmware versions mentioned. Minor signal-path timing differences between v4.1 and v4.2 are all that distinguish the two versions, in this particular case. If an earlier version of firmware works better for your particular board than does a later version then by all means use what works for you. 73, Joe K5SO On Aug 27, 2014, at 3:23 AM, Brian D wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I've reverted to 4.1 firmware. The NaN problem has disappeared so it looks > as if the angelia 4.2 firmware is the problem. > > > Jae Stutzman wrote: > I should have mentioned that I recently upgraded to 4.2 Angelia as well. So > it could be either. I'll try downgrading back to 4.1 to see if that changes > anything. I noticed it with TUN and it was reading out about 85W for each > band. I was originally trying to find out if I was affected by the 10M > winding issue. > > > On Tue, Aug 26, 2014 at 4:54 AM, Brian D wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Jae Stutzman wrote: > >> Is it just me or does the fwd pwr TX meter seem to be to be reading lower >> than it should with this release? I was checking power outputs and it >> seems to be about 15 watts lower than reality. Is this just me? I was >> trying to adjust output power and that's when I realized it. I reset >> databases just to be sure. I didn't notice this on 3.2.17. > > I haven't noticed it reading low but I've had several times it reading NaN > for VSWR when tuning into the goood match of my test load. Not sure at this > stage if it is the new version of HPSDR or my recent firmware upgrade to 4.2 > (angelia). > > > -- > Brian D > G3VGZ > From ad0es at ad0es.net Wed Aug 27 07:19:06 2014 From: ad0es at ad0es.net (AD0ES) Date: Wed, 27 Aug 2014 08:19:06 -0600 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: Hi, I have been slowly dipping my toes into the SDR pool, have a mercury rcvr setup functioning now. Excited about the direction new development is taking, especially in the area of moving more of the work from FPGA to a general class cpu/gpu. Next step for me is to setup with the tools necessary to write FPGA/gpu/openCL code. I spent some time on the Altera(?) site and went away totally confused. Are there tools available allowing one to design/write/compile FPGA code for these beasts without paying license fees or BEING CONNECTED to the net while using? I have no internet access at home and need a non-inet solution. If someone could provide a cookbook list of where/how to get the tools I believe it would get more people started down this path. tia, Steve AD0ES On Aug 26, 2014, at 1:59 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > In an effort to assist in making the timing closure tasks associated with OpenHPSDR firmware development less intimidating and easier for beginners to participate I have prepared a PDF document that describes a standardized procedure that I use for the task. The document may be downloaded from From k5so at valornet.com Wed Aug 27 07:51:49 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Wed, 27 Aug 2014 08:51:49 -0600 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: <8D51197B-0E5F-4B20-86A6-AB8D93FB0713@valornet.com> Hi Steve, With regard to the necessary FGPA tools, you need only the free Quartus II program download from: https://www.altera.com/download/sw/dnl-sw-index.jsp at the bottom of the page is a window that allows you to select to download any version of Quartus II from v2.2 to v14.0. As you are working with Atlas-based boards I would suggest that the latest version for you work with should be v13.0 as later versions do not support the Cyclone II FPGA used in Penelope and the latest v14.0 does not support the Cyclone III FPGA used in Mercury. Quartus II will run just fine without being connect to the internet. You will receive a startup message that Quartus II can?t get to the Quartus website to check for updates but simply close the window and things will be fine. 73, Joe K5SO On Aug 27, 2014, at 8:19 AM, AD0ES wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi, > > I have been slowly dipping my toes into the SDR pool, have a mercury rcvr setup functioning now. Excited about the > direction new development is taking, especially in the area of moving more of the work from FPGA to a general class > cpu/gpu. Next step for me is to setup with the tools necessary to write FPGA/gpu/openCL code. > > I spent some time on the Altera(?) site and went away totally confused. Are there tools available allowing one to > design/write/compile FPGA code for these beasts without paying license fees or BEING CONNECTED to the net while using? > I have no internet access at home and need a non-inet solution. > > If someone could provide a cookbook list of where/how to get the tools I believe it would get more people started down > this path. > > tia, > Steve AD0ES > From wb9qzb_groups at yahoo.com Wed Aug 27 07:47:34 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Wed, 27 Aug 2014 07:47:34 -0700 Subject: [hpsdr] DCC Proceedings Abstracts Announced - 2014 ARRL/TAPR Digital Communications Conference Austin, TX September 5-7, 2014 In-Reply-To: <1409150515.91658.YahooMailNeo@web140204.mail.bf1.yahoo.com> References: <1409150515.91658.YahooMailNeo@web140204.mail.bf1.yahoo.com> Message-ID: <1409150854.72388.YahooMailNeo@web140201.mail.bf1.yahoo.com> http://www.tapr.org/pub_dcc33.html DCC Proceedings Abstracts: 33rd ARRL and TAPR Digital Communications Conference September 5-7, 2014 ________________________________ High-Speed Wireless Networking in the UHF and Microwave Bands? by?David Bern, W2LNX?and?Keith Elkin, KB3TCB Abstract:?This paper discusses building an amateur radio wireless network using commercial off the shelf wireless networking equipment that is currently available. As an example, four Ubiquiti NanoStation M3 3.4 GHz digital radios are used to assemble a demonstration network of two wireless network links that operate on two different frequencies. In conclusion, the paper invites the amateur radio community to build a nationwide highspeed amateur radio wireless backbone network to connect all local amateur radio area community wireless networks. Proceedings Paper Clarifying the Amateur Bell 202 Modem? by?Kenneth W. Finnegan, W6KWF?and?Bridget Benson, PhD The Stream Control Transmission Protocol (SCTP) and Its Potential for Amateur Radio? by?Eduardo Gonzalez?,?Dr Stan McClellan?and?Dr Wuxu Peng SDR-based DATV-Express Exciter for Digital-ATV? by?Ken Konechy, W6HHC A Radioteletype Over-Sampling Software Decoder for Amateur Radio? by?Joseph J. Roby, Jr, K0JJR An HF Frequency-Division Multiplex (FDM) Modem? by?Steven Sampson, K5OKC Modulation - Demodulation Software Radio? by?Alex Schwarz VE7DXW?and?Guy Roels ON6MU Installing a LIF port into the FT-950 transceiver? by?Alex Schwarz, VE7DXW Installing a LIF port into the IC-756ProIII transceiver? by?Alex Schwarz, VE7DXW The European HAMNET - A Large Scale High Speed Radio Network? by?Jann Traschewski, DG8NGN Implementation of Basic Analog and Digital Modulation Schemes using a SDR Platform? by?Jose M. Valencia?and?Omar H. Longoria -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjablonski at att.net Wed Aug 27 11:06:22 2014 From: bjablonski at att.net (Barry Jablonski) Date: Wed, 27 Aug 2014 14:06:22 -0400 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: <53FE1E1E.6050304@att.net> Hi Steve. Here is a link to a PDF of Altera's "Intro to Quartus II": www.altera.com/literature/manual/intro_to_quartus2.pdf Hope it helps. Barry WB2ZXJ From scotty at tonks.com Thu Aug 28 13:43:06 2014 From: scotty at tonks.com (Scott Cowling) Date: Thu, 28 Aug 2014 13:43:06 -0700 Subject: [hpsdr] Success with GNURadio on LIVA PC! In-Reply-To: <53FE1E1E.6050304@att.net> References: <53FE1E1E.6050304@att.net> Message-ID: <7.0.1.0.2.20140828130549.056c7120@tonks.com> Hi all, This is not strictly HPSDR related, but I thought that most would be interested is the SDR capabilities of the ECS LIVA PC that is on sale at Newegg for $132 through Friday. I got the LIVA on Wednesday and assembled it. (Be careful with those little MMCX connectors for the WiFi antenna. I broke one of them and had to repair it, which was not fun.) I installed Ubuntu 14.04 from a USB flash drive, then downloaded and ran the GNURadio install script for version 3.7.4. Then I downloaded the SDRstick source block and followed the instructions to build and install it (only about 6 steps). I plugged in my HF1 and BeMicroSDK hardware to the USB port (for power) and the GigE port (for data). Amazingly, it came right up! The sample AM receiver flowgraph works, and at 384K bandwidth I can hear (and see) AM broadcast stations with no dropouts. This is pretty exciting for such a small, low-power PC! When I go to 1.25MHz bandwidth, the receiver still works, but the PC just can't keep the graphics on the screen updated. I haven't tweaked any priorities yet, but it looks like 1.25MHz is a bit too much for this "little PC that could"! I will bring this setup to DCC next weekend to demo. 73, Scotty WA2DFI From g4hup at btinternet.com Thu Aug 28 15:01:06 2014 From: g4hup at btinternet.com (dave powis) Date: Thu, 28 Aug 2014 23:01:06 +0100 Subject: [hpsdr] FS - Hermes set-up Message-ID: <1409263266.99171.YahooMailNeo@web87703.mail.ir2.yahoo.com> For sale - my Hermes set up, comprising: TAPR Hermes mounted in Hammond case, with additional chip heatsink and external power connector N8UR breakout board for J16 Munin PA kit with heatsink and Hammond case (not assembled). Looking for ?800.? Shipping to be discussed - preference to UK sale. Also available Alex Tx/Rx Filter set in housing? - assembled, with cables Looking for ?300. Shipping to be discussed - preference to UK sale. Please contact me off-list at g4hup-at-btinternet-dot-com Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From lstoskopf at cox.net Thu Aug 28 21:05:17 2014 From: lstoskopf at cox.net (lstoskopf at cox.net) Date: Fri, 29 Aug 2014 0:05:17 -0400 Subject: [hpsdr] Success with GNURadio on LIVA PC! In-Reply-To: Message-ID: <20140829000517.QTPFP.168732.imail@eastrmwml107> Great. Some of us did the Kickstarter thing to have the talks put on HamTV (I think). Hit him up for a quick segment on your setup and operation. Awaiting the new AC9 board. N0UU From jkelly at verizon.net Fri Aug 29 03:07:06 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 29 Aug 2014 06:07:06 -0400 Subject: [hpsdr] WTB Funcube Dongle Pro Message-ID: <0NB2007XYC3WYBA0@vms173015.mailsrvcs.net> Send email to: K2SDR at verizon.net Jeff From wb9qzb_groups at yahoo.com Fri Aug 29 12:30:21 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Fri, 29 Aug 2014 12:30:21 -0700 Subject: [hpsdr] ARRL/TAPR DCC Speaker Schedule Announced, Austin, TX, 9/5 - 9/7/14 (Walk-In Registrations at DCC Welcome) In-Reply-To: <8D191D64470CED4-1EF4-448A@webmail-vd010.sysops.aol.com> References: <1409340051.42235.YahooMailNeo@web140202.mail.bf1.yahoo.com> <8D191D5E158017D-1EF4-443D@webmail-vd010.sysops.aol.com> <8D191D64470CED4-1EF4-448A@webmail-vd010.sysops.aol.com> Message-ID: <1409340621.78960.YahooMailNeo@web140201.mail.bf1.yahoo.com> DCC Speaker Schedule Announced 2014 ARRL/TAPR Digital Communications Conference Austin, TX September 5 - 7, 2014 http://www.tapr.org/pdf/DCC_2014_Schedule_2014-08-27.pdf Register for the DCC Walk-in registrations at DCC are very welcome. Online Registration Form https://www.tapr.org/dccregistration.php Pre-registration will close on August 30th to allow the office staff to complete preparations (print badges and stuff envelopes) and travel to the conference. Use of the on-line registration form after August 30th is encouraged, as it will save time at the registration desk filling in hard copy forms and wait for credit card processing.. Tucson Amateur Packet Radio Phone: (972) 671-TAPR (8277) Contact TAPR Office: http://www.tapr.org/inforequest.php -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkelly at verizon.net Fri Aug 29 15:17:12 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 29 Aug 2014 18:17:12 -0400 Subject: [hpsdr] WTB Funcube Dongle Pro In-Reply-To: <0NB2007XYC3WYBA0@vms173015.mailsrvcs.net> References: <0NB2007XYC3WYBA0@vms173015.mailsrvcs.net> Message-ID: <594C7EC51FA641619B6FBBD3FBAEFBAE@JeffPC> Thank you got one. Jeff -----Original Message----- From: Jeff Kelly Sent: Friday, August 29, 2014 6:07 To: hpsdr at openhpsdr.org Subject: [hpsdr] WTB Funcube Dongle Pro ***** High Performance Software Defined Radio Discussion List ***** Send email to: K2SDR at verizon.net Jeff _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From w5wc at windstream.net Fri Aug 29 16:54:12 2014 From: w5wc at windstream.net (Doug Wigley) Date: Fri, 29 Aug 2014 18:54:12 -0500 Subject: [hpsdr] PowerSDR/OpenHPSDR mRX PS v3.2.19 released Message-ID: <00ad01cfc3e4$88b755f0$9a2601d0$@net> All, PowerSDR/OpenHPSDR mRX PS v3.2.19 has been released. Bug fixes added for the following problems: - APF text field in the VFOA window masked part of the VHF frequency. - Unable to use the DJ Console with CTUN enabled. Added colors to the diversity "Enable" button. Green = ON, Red = OFF. No database reset required! This release can be downloaded from the openhpsdr.org website. http://openhpsdr.org/download.php 73, Doug W5WC From mlalonde at alphatronique.com Fri Aug 29 17:29:08 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Fri, 29 Aug 2014 20:29:08 -0400 Subject: [hpsdr] Success with GNURadio on LIVA PC! In-Reply-To: <7.0.1.0.2.20140828161242.05444838@tonks.com> References: <53FE1E1E.6050304@att.net> <7.0.1.0.2.20140828130549.056c7120@tonks.com> <53FFA0FB.2090201@alphatronique.com> <7.0.1.0.2.20140828161242.05444838@tonks.com> Message-ID: <54011AD4.2080806@alphatronique.com> Hi first that really small PC ! next it require a "UEFI" bootable USB key AND a 64Bit win 8.1 for work anything else fail to boot and/or install ,i lost big part of my day figure it ... i make work whit decent performance of 2 or less decoding WSJT-X (not forget the NTP server) JT65HF-109 one that not work JT65-HF HB9HQX remain on "receiving" so whit my KX3 i made nice portable JT65 setup and\or monitor for 6M opening 73 .. Marc L VE2OLM On 28/08/2014 7:13 PM, Scott Cowling wrote: > Hi Marc, > > Sounds like a good use for one! I would like to hear about your setup > when you get it running. > > 73, > Scotty WA2DFI > > At 17:36 2014-08-28 -0400, you wrote: >> Hi >> >> Thank i have order one for try to use it for monitor 6M Band opening >> whit JT65A >> >> 73 >> Marc VE2OLM >> >> On 28/08/2014 4:43 PM, Scott Cowling wrote: >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> Hi all, >>> >>> This is not strictly HPSDR related, but I thought that most would be >>> interested is the SDR capabilities of the ECS LIVA PC that is on >>> sale at Newegg for $132 through Friday. >>> >>> I got the LIVA on Wednesday and assembled it. (Be careful with those >>> little MMCX connectors for the WiFi antenna. I broke one of them and >>> had to repair it, which was not fun.) >>> >>> I installed Ubuntu 14.04 from a USB flash drive, then downloaded and >>> ran the GNURadio install script for version 3.7.4. Then I downloaded >>> the SDRstick source block and followed the instructions to build and >>> install it (only about 6 steps). >>> >>> I plugged in my HF1 and BeMicroSDK hardware to the USB port (for >>> power) and the GigE port (for data). >>> >>> Amazingly, it came right up! The sample AM receiver flowgraph works, >>> and at 384K bandwidth I can hear (and see) AM broadcast stations >>> with no dropouts. This is pretty exciting for such a small, >>> low-power PC! >>> >>> When I go to 1.25MHz bandwidth, the receiver still works, but the PC >>> just can't keep the graphics on the screen updated. I haven't >>> tweaked any priorities yet, but it looks like 1.25MHz is a bit too >>> much for this "little PC that could"! >>> >>> I will bring this setup to DCC next weekend to demo. >>> >>> 73, >>> Scotty WA2DFI >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: >>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > From aa8k73 at gmail.com Fri Aug 29 19:31:47 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 29 Aug 2014 22:31:47 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/30 Message-ID: <54013793.3030108@gmail.com> The 30/Aug TeamSpeak mp3 (67 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3513 > or < http://www.hamsdr.com/dnld.aspx > Only silence truncation editing was done on this recording. From dc6ny at gmx.de Sun Aug 31 02:49:41 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Sun, 31 Aug 2014 11:49:41 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> <53FCB91C.1090209@alphatronique.com> Message-ID: <000001cfc500$e38379b0$aa8a6d10$@de> Hi, I read a topical notification of the USB Promoter Group (HP, Intel, MS, Renesas Elec, TI ) that USB 3.1 will be already available end of 2014. This smart (cheap) interface could be one option for a fast 10 Gbit/s connection of future broadband DDC/DUC hardware and versatile computer architectures. I think it's certainly worth to watch further progress and market. 73, Helmut, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von John Laur Gesendet: Dienstag, 26. August 2014 22:27 An: HPSDR list Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** All, Thank you for the good discussion. My intention was not to focus too much on the Jetson discussion actually; I do know that if the code runs on Jetson I can happily build a small linux machine that will also run it, so nobody is "locking" anyone into any particular thing. I just think the Jetson is a low mark to aim for. If it can do a realtime 30mHz FFT, so can basically any current GPU. Even low power cards like the GeForce 750 Ti will run circles around it, while drawing 60W and costing less. I think anyone who has ever compiled up the fosphor plugin on GNU Radio has probably lamented not having that view available all the time. So I wont beat on Jetson any more. I just thought while we were on the subject of architectures it would be a good time to cut to the chase on the bandwidth problem. While I will agree with Hermann that SDR hardware (and the HDL features of HPSDR) seem to be changing as fast or faster than SDR software in recent months, I also think it ought to be the other way around. On the big list of SDR's from Wikipedia http://en.wikipedia.org/wiki/List_of_software-defined_radios I note only 2 devices use PCIe. I think the hardware is changing largely because of all the ways that developers are choosing to deal with the problems of interface constraints; hardware that can filter this amount of data at this datarate is neither easy nor cheap to engineer. There is no need to go to this length if you can just move all the data in the first place. But if the GPU architecture is the way forward, it's just silly to put an intermediate interface that requires a lot of HDL work in the way. For a direct sampling design the most future proof design possible is to make sure the hardware is at minimum capable of sending the raw ADC/DAC/Clock data in and out at full datarate to an attached device. IMO the reason working with the SoCKit hardware and Scotty's boards is probably so nice is because the interface from the FPGA to the software is basically transparent. (This is half speculation as I have a SoCKit that I have used quite a bit but have not yet put funds together for a board set from Scotty) There is no ethernet PHY and framing and protocol to get at the DDC data; the CPU just opens a device and starts reading. If That eliminates a lot of complexity. But you could easily plug his board set into a different dev kit like this http://www.altera.com/products/devkits/altera/kit-cyclone-v-gt.html and with some (admitted) effort you could make yourself a prototype PCIe HPSDR card right now that could do DMA transfers of ADC samples right into GPU memory with the same sort of ease. This is the beauty of a high speed interconnect standard. In this case it is HSMC, useful only within a certain scope, but it makes the point I think. A comment for Marc: From what I have seen Mini-PCIe is generally only ever offered with a x1 interface with the exception of MXM, so it makes more sense to adapt a PCIe card to the mini-PCIe form factor than vice versa; that way the card can be designed as a 4x or such. (It can always be allowed to fall back to 1x) Anyway to sum it all up neatly, a single integrated board like Hermes with a Cyclone V SoC part on board that can be used standalone or plugged in and used as a PCIe card would be pretty attractive HPSDR platform, I gotta say. 73, John KF5SAB _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ From k5so at valornet.com Sun Aug 31 09:29:55 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 31 Aug 2014 10:29:55 -0600 Subject: [hpsdr] Orion/ANAN-200D Orion_v2.7 firmware package release Message-ID: <4571643A-37A2-4780-97D1-3D70793B24C8@valornet.com> All, Orion_v2.7 firmware package is available for download from http://www.k5so.com/HPSDR_downloads.html This version of firmware fixes a failure to key an external amplifiler via the PTT output connector when keyed via the external PTT input pin of the accessory jack when in CW mode and improper behavior of non-breakin CW PTT functionality. I have alerted Phil and Abhi that this issue, corrected earlier in Angelia firmware, exists in any of our firmware designs that have implemented CW generated withing the FPGA, including Hermes and Atlas-based systems. It is my expectation that they will shortly release new versions of their respective firmware packages to include this fix which has now already been applied to the Angelia and Orion firmware. 73, Joe K5SO From wb4gcs at wb4gcs.org Sun Aug 31 11:29:21 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Sun, 31 Aug 2014 14:29:21 -0400 Subject: [hpsdr] Multiple Metis on one Ethernet Message-ID: <54036981.2020709@wb4gcs.org> All: Have one HPSDR running. Building the second. FOr now, mercury is set to obtain IP address via DHCP. Any problems putting the second one on the network to update firmware in my very old mercury and penny boards? Thanks & 73, Jim wb4gcs at amsat.org --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From beford at myfairpoint.net Sun Aug 31 13:01:55 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Sun, 31 Aug 2014 16:01:55 -0400 Subject: [hpsdr] Munin amp kits for sale Message-ID: I purchased two complete kits for Munin when they were offered by Don, K3DLW, but have not built either yet. I would be willing to sell both for what I paid, plus postage. This also includes the PC boards , all components, heat sinks and copper heat spreaders. That would come to $170 each total, including Priority mail to your US address. Check, Money Order, or PayPal would be fine. Please reply off-list. mycall at arrl dot net Thanks, Bruce/N1RX -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 13:30:30 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 15:30:30 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 Message-ID: After about 3 hours worth of work and a few workarounds, I made my first QSO on 20 meters under Linux! I used MonoDevelop as the IDE for the C# KISS solution. I had to make a couple of changes for the P/Invokes of the fftw3f library and some of the Networking calls, which are still not implemented within the Mono CLR. The performance is quite good, I'll compare it to my Windows box to see the differences. Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. I'll document my changes and the dependencies that I installed to make it work soon. Thanks everyone for the welcome and thanks to the authors of KISS Konsole for making the porting easy :) 73, Jae - K5JAE -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 13:36:38 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 15:36:38 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: The link should not have the following '.' at the end. Here it is again: http://i.imgur.com/AsJ4pSE.png On Sun, Aug 31, 2014 at 3:30 PM, Jae Stutzman wrote: > After about 3 hours worth of work and a few workarounds, I made my first > QSO on 20 meters under Linux! > > I used MonoDevelop as the IDE for the C# KISS solution. I had to make a > couple of changes for the P/Invokes of the fftw3f library and some of the > Networking calls, which are still not implemented within the Mono CLR. The > performance is quite good, I'll compare it to my Windows box to see the > differences. > > Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. > I'll document my changes and the dependencies that I installed to make it > work soon. > > Thanks everyone for the welcome and thanks to the authors of KISS Konsole > for making the porting easy :) > > > 73, > > Jae - K5JAE > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.frohne at wallawalla.edu Sun Aug 31 15:12:51 2014 From: rob.frohne at wallawalla.edu (Rob Frohne) Date: Sun, 31 Aug 2014 14:12:51 -0800 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: That's neat Jae! 73, Rob KL7NA On August 31, 2014 12:36:38 PM AKDT, Jae Stutzman wrote: >***** High Performance Software Defined Radio Discussion List ***** > > > >------------------------------------------------------------------------ > >The link should not have the following '.' at the end. Here it is >again: >http://i.imgur.com/AsJ4pSE.png > > > >On Sun, Aug 31, 2014 at 3:30 PM, Jae Stutzman >wrote: > >> After about 3 hours worth of work and a few workarounds, I made my >first >> QSO on 20 meters under Linux! >> >> I used MonoDevelop as the IDE for the C# KISS solution. I had to make >a >> couple of changes for the P/Invokes of the fftw3f library and some of >the >> Networking calls, which are still not implemented within the Mono >CLR. The >> performance is quite good, I'll compare it to my Windows box to see >the >> differences. >> >> Here is a link to a screenshot of how it looks: >http://imgur.com/AsJ4pSE. >> I'll document my changes and the dependencies that I installed to >make it >> work soon. >> >> Thanks everyone for the welcome and thanks to the authors of KISS >Konsole >> for making the porting easy :) >> >> >> 73, >> >> Jae - K5JAE >> >> >> >> > > >------------------------------------------------------------------------ > >_______________________________________________ >HPSDR Discussion List >To post msg: hpsdr at openhpsdr.org >Subscription help: >http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >HPSDR web page: http://openhpsdr.org >Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wb4gcs at wb4gcs.org Sun Aug 31 14:57:25 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Sun, 31 Aug 2014 17:57:25 -0400 Subject: [hpsdr] Trouble updating Mercury firmware Message-ID: <54039A45.8020804@wb4gcs.org> All: I am finally assembling the system I purchased in pieces long ago from TAPR. I have successfully updated Metis firmware to the latest. I have installed J1 in Metis to put it in bootloader mode. I have installed J7 (last JTAG) jumper on Mercury. Running HPSDRProgrammer V2 version 2.0.4.0 All the LEDs on Mercury that the manual says should be lit are. When I click DISCOVER, Mercury is not found, and I get an error message telling me to "Make sure the correct interface is attached. There is only one interface -- the ethernet interface on the computer. Any suggestions?? Thanks & 73, Jim wb4gcs at amsat.org --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From k5jae at stutzman.net Sun Aug 31 15:54:22 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 17:54:22 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: On a whim, I thought I might try the Jetson TK1 board with mono/kiss konsole. After working out the dependencies, it appears to run OK (I haven't transmitted yet). Anything beyond 96000 sample rate will give audio distortion on the receive. If I choose 192000 and then select NR, it really goes off the rails. Keep in mind that this is completely running within the ARM hard float CPU, which is using the original libfftw3 FFT library. Utilizing a CUDA optimized FFT library would probably give a lot more headroom. Both the spectrum and waterfall displays are ok with some slight hiccup that correspond to audio blips. 73, Jae - K5JAE On Sun, Aug 31, 2014 at 5:12 PM, Rob Frohne wrote: > That's neat Jae! > > 73, > Rob > KL7NA > > On August 31, 2014 12:36:38 PM AKDT, Jae Stutzman > wrote: >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> The link should not have the following '.' at the end. Here it is again: >> http://i.imgur.com/AsJ4pSE.png >> >> >> >> On Sun, Aug 31, 2014 at 3:30 PM, Jae Stutzman wrote: >> >>> After about 3 hours worth of work and a few workarounds, I made my first >>> QSO on 20 meters under Linux! >>> >>> I used MonoDevelop as the IDE for the C# KISS solution. I had to make a >>> couple of changes for the P/Invokes of the fftw3f library and some of the >>> Networking calls, which are still not implemented within the Mono CLR. The >>> performance is quite good, I'll compare it to my Windows box to see the >>> differences. >>> >>> Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. >>> I'll document my changes and the dependencies that I installed to make it >>> work soon. >>> >>> Thanks everyone for the welcome and thanks to the authors of KISS >>> Konsole for making the porting easy :) >>> >>> >>> 73, >>> >>> Jae - K5JAE >>> >>> >>> >>> >> ------------------------------ >> >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Sun Aug 31 16:09:32 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 31 Aug 2014 17:09:32 -0600 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: <6B339E1F-4D1A-4AF4-9404-386B050807B3@valornet.com> Congratulations, Jae! That?s excellent news! I have just this past Thursday assembled a new computer system to allow me to begin exploring Linux. I have installed Ubuntu, Synaptic, Mono-complete, MonoDevelop and am anxious to get rolling on porting some of my Windows C# radio astronomy apps that I have written over to Linux. I am ecstatic to hear that you have KISS ported over now (in such a brief time too!!) and I am very interested to see how you did it. Also, I too have a strong interest in porting PowerSDR over to Linux and I have heard of your vast experience in such porting activities. I am quite excited to learn of any progress that you make there so please do give us updates as to your progress. I, naively of course, intended to give it a try myself as soon as I gain more familiarity with Linux, and Mono in particular. I currently use Visual Studio 2013 to make mods to the PowerSDR code from time to time but I?m not a professional programmer and barely squeak along with VS to be truthful; but I?m continuing to learn all the time and am getting more proficient, I hope. I am a complete newbie with respect to Linux so please don?t be overly brief in your ?how to? descriptions or they?ll go completely over my head for sure. Thanks, and congrats again! 73, Joe K5SO From g3vbv at blueyonder.co.uk Sun Aug 31 16:20:51 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 01 Sep 2014 00:20:51 +0100 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: <5403ADD3.2020209@blueyonder.co.uk> Neat. Back in May 2013 I posted the following but didn't get a reply. This was using the .exe under Crossover Office. ------------------------------------------------------------------------------------ For curiosity value mainly. Just seeing if anyone has an idea what's happening. Appending screenshots exceeds the allowed email limit. I select HERMES and when I click ON I get a string of these messages, it sees Hermes on 192.168.10.77 then the 127.12.34.56 Metis stuff, Metis is not selected, only Hermes with 2.4 firmware. Found a Metis/Hermes/Griffin. Checking whether it qualifies Metis IP from IP Header = 192.168.10.77 Metis MAC address from payload = 00-04-A3-6A-21-BE Not on subnet of host adapter! Adapter IP 127.12.34.56, Adapter mask 255.255.255.255 No data from Port = Ready to receive.... raw Discovery data = EF-FE-02-00-04-A3-6A-21-BE-18-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 -01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 ----------------------------------------------------------------------------------------------------------------------- 73 ... Sid. On 31/08/14 21:30, Jae Stutzman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > After about 3 hours worth of work and a few workarounds, I made my > first QSO on 20 meters under Linux! > > I used MonoDevelop as the IDE for the C# KISS solution. I had to make > a couple of changes for the P/Invokes of the fftw3f library and some > of the Networking calls, which are still not implemented within the > Mono CLR. The performance is quite good, I'll compare it to my Windows > box to see the differences. > > Here is a link to a screenshot of how it looks: > http://imgur.com/AsJ4pSE. I'll document my changes and the > dependencies that I installed to make it work soon. > > Thanks everyone for the welcome and thanks to the authors of KISS > Konsole for making the porting easy :) > > > 73, > > Jae - K5JAE > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 16:25:48 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 18:25:48 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: <6B339E1F-4D1A-4AF4-9404-386B050807B3@valornet.com> References: <6B339E1F-4D1A-4AF4-9404-386B050807B3@valornet.com> Message-ID: Joe, This is obviously a proof of concept at this point. Some of the issues I experienced years ago with Mono and WinForms are still there. Namely, rendering issues. On Windows, WinForms is a thin wrapper on top of native Windows libraries. On Linux, the Mono team wrote the entire library in managed code before diving into the native X Windows UI layer. What I find is that initial widget rendering is a bit slow and then size and location of widgets don't always render correctly. However, the UI seems usable. I'll definitely relay my findings to this group. More to follow :) 73, Jae - K5JAE On Aug 31, 2014 6:09 PM, "Joe Martin K5SO" wrote: > Congratulations, Jae! That?s excellent news! > > I have just this past Thursday assembled a new computer system to allow me > to begin exploring Linux. I have installed Ubuntu, Synaptic, > Mono-complete, MonoDevelop and am anxious to get rolling on porting some of > my Windows C# radio astronomy apps that I have written over to Linux. I am > ecstatic to hear that you have KISS ported over now (in such a brief time > too!!) and I am very interested to see how you did it. > > Also, I too have a strong interest in porting PowerSDR over to Linux and I > have heard of your vast experience in such porting activities. I am quite > excited to learn of any progress that you make there so please do give us > updates as to your progress. I, naively of course, intended to give it a > try myself as soon as I gain more familiarity with Linux, and Mono in > particular. I currently use Visual Studio 2013 to make mods to the > PowerSDR code from time to time but I?m not a professional programmer and > barely squeak along with VS to be truthful; but I?m continuing to learn all > the time and am getting more proficient, I hope. > > I am a complete newbie with respect to Linux so please don?t be overly > brief in your ?how to? descriptions or they?ll go completely over my head > for sure. > > Thanks, and congrats again! > > 73, Joe K5SO > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 17:03:01 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 19:03:01 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: <5403ADD3.2020209@blueyonder.co.uk> Message-ID: Sid, I've only used CrossOver for a couple of things. There is a big difference to running and exe within CX and Mono. First, CX is a reimplementation of win32/64 native libraries under Linux and libc. It intends to allow win apps to run as though they are on windows. This means you install .NET on top of CX to run C# apps. It has been moderately successful and a huge undertaking! Mono, on the other hand is a reimplementation of the CLR/CLI. It doesn't bring in any win32/64 APIs and is a clean room implementation. It would be analogous to the JVM running on Linux vs running on Windows, except that MS didn't provide a Linux version so the OSS community wrote it themselves. I view CX as a compromise to bring windows applications to Linux. I view Mono as a first class development and runtime environment where Linux apps can be made and executed. That said. I like cross platform development. With careful consideration an app can look and run as if native on many different platforms. As far as your log, I'm not sure what was going on! Except it looks like it had something to do with the network interface. 73, Jae > On Aug 31, 2014 6:20 PM, "Sid Boyce" wrote: >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> >> Neat. >> Back in May 2013 I posted the following but didn't get a reply. This was using the .exe under Crossover Office. >> ------------------------------------------------------------------------------------ >> For curiosity value mainly. >> Just seeing if anyone has an idea what's happening. >> Appending screenshots exceeds the allowed email limit. >> >> I select HERMES and when I click ON I get a string of these messages, it sees Hermes on 192.168.10.77 then the 127.12.34.56 Metis stuff, Metis is not selected, only Hermes with 2.4 firmware. >> >> Found a Metis/Hermes/Griffin. Checking whether it qualifies >> Metis IP from IP Header = 192.168.10.77 >> Metis MAC address from payload = 00-04-A3-6A-21-BE >> Not on subnet of host adapter! Adapter IP 127.12.34.56, Adapter mask 255.255.255.255 >> No data from Port = >> Ready to receive.... >> raw Discovery data = EF-FE-02-00-04-A3-6A-21-BE-18-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 >> -01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 >> ----------------------------------------------------------------------------------------------------------------------- >> 73 ... Sid. >> >> On 31/08/14 21:30, Jae Stutzman wrote: >>> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> >>> >>> After about 3 hours worth of work and a few workarounds, I made my first QSO on 20 meters under Linux! >>> >>> I used MonoDevelop as the IDE for the C# KISS solution. I had to make a couple of changes for the P/Invokes of the fftw3f library and some of the Networking calls, which are still not implemented within the Mono CLR. The performance is quite good, I'll compare it to my Windows box to see the differences. >>> >>> Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. I'll document my changes and the dependencies that I installed to make it work soon. >>> >>> Thanks everyone for the welcome and thanks to the authors of KISS Konsole for making the porting easy :) >>> >>> >>> 73, >>> >>> Jae - K5JAE >>> >>> >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> >> >> -- >> 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 >> >> >> _______________________________________________ >> >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wp4o at tampabay.rr.com Sun Aug 31 17:42:30 2014 From: wp4o at tampabay.rr.com (ed) Date: Sun, 31 Aug 2014 20:42:30 -0400 Subject: [hpsdr] anan 100 forsale Message-ID: <000001cfc57d$9cad2310$d6076930$@tampabay.rr.com> Selling my extra ANAN 100 has new Smps regulator and VCXO Runs very cool. E mail me if interested. Thanks and 73, Ed KK4x, Tampa Florida -------------- next part -------------- An HTML attachment was scrubbed... URL: From kv0s.dave at gmail.com Sun Aug 31 18:15:24 2014 From: kv0s.dave at gmail.com (Dave Larsen) Date: Sun, 31 Aug 2014 20:15:24 -0500 Subject: [hpsdr] Trouble updating Mercury firmware In-Reply-To: <54039A45.8020804@wb4gcs.org> References: <54039A45.8020804@wb4gcs.org> Message-ID: Jim Almost right There are two programs, HPSDRProgrammer V2 only talks to boards with ethernet sockets and does not need the j1 jumper but it will not program through a JTAG port. the second program HPSDRBootloader is for use in the Bootloader mode as you specified. If you follow your steps, EXCEPT use HPSDRBootloader it should work.. HPSDRBootloader uses the pcap library, the J1 jumper and a raw Ethernet packets and cane be used as a JTAG programmer for boards with no Ethernet connector. HPSDRProgrammer V2 is use UDP, no jumper and old firmware newer that 2.3, This is convenients for update firmware without opening the box. But if the old firmware is broke it will not work. PS. HPSDRProgrammer V1.6 does both tasks but people got confused different problem and what part of the program when with each task. Dave KV0S HPSDRProgrammer V2 and HPSDRBootloader Programmer and Maintainer On Sun, Aug 31, 2014 at 4:57 PM, Jim Sanford wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All: > I am finally assembling the system I purchased in pieces long ago from > TAPR. > > I have successfully updated Metis firmware to the latest. > > I have installed J1 in Metis to put it in bootloader mode. > > I have installed J7 (last JTAG) jumper on Mercury. > > Running HPSDRProgrammer V2 version 2.0.4.0 > > All the LEDs on Mercury that the manual says should be lit are. > > When I click DISCOVER, Mercury is not found, and I get an error message > telling me to "Make sure the correct interface is attached. There is only > one interface -- the ethernet interface on the computer. > > Any suggestions?? > > Thanks & 73, > Jim > wb4gcs at amsat.org > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/ > listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- KV0S - Dave Larsen Columbia, MO, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: From wb4gcs at wb4gcs.org Sun Aug 31 18:21:11 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Sun, 31 Aug 2014 21:21:11 -0400 Subject: [hpsdr] Trouble updating Mercury firmware In-Reply-To: References: <54039A45.8020804@wb4gcs.org> Message-ID: <5403CA07.2010802@wb4gcs.org> That did it, thanks!!!!! 73, Jim wb4gcs at amsat.org On 8/31/2014 9:15 PM, Dave Larsen wrote: > Jim > > Almost right > > There are two programs, HPSDRProgrammer V2 only talks to boards with > ethernet sockets and does not need the j1 jumper but it will not > program through a JTAG port. > > the second program HPSDRBootloader is for use in the Bootloader mode > as you specified. If you follow your steps, EXCEPT use > HPSDRBootloader it should work.. > > HPSDRBootloader uses the pcap library, the J1 jumper and a raw > Ethernet packets and cane be used as a JTAG programmer for boards with > no Ethernet connector. > > HPSDRProgrammer V2 is use UDP, no jumper and old firmware newer that > 2.3, This is convenients for update firmware without opening the box. > But if the old firmware is broke it will not work. > > > PS. HPSDRProgrammer V1.6 does both tasks but people got confused > different problem and what part of the program when with each task. > > Dave KV0S HPSDRProgrammer V2 and HPSDRBootloader Programmer and > Maintainer > > > On Sun, Aug 31, 2014 at 4:57 PM, Jim Sanford > wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > All: > I am finally assembling the system I purchased in pieces long ago > from TAPR. > > I have successfully updated Metis firmware to the latest. > > I have installed J1 in Metis to put it in bootloader mode. > > I have installed J7 (last JTAG) jumper on Mercury. > > Running HPSDRProgrammer V2 version 2.0.4.0 > > All the LEDs on Mercury that the manual says should be lit are. > > When I click DISCOVER, Mercury is not found, and I get an error > message telling me to "Make sure the correct interface is > attached. There is only one interface -- the ethernet interface on > the computer. > > Any suggestions?? > > Thanks & 73, > Jim > wb4gcs at amsat.org > > > --- > This email is free from viruses and malware because avast! > Antivirus protection is active. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > > -- > KV0S - Dave Larsen > Columbia, MO, USA --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From beford at myfairpoint.net Sun Aug 31 18:41:29 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Sun, 31 Aug 2014 21:41:29 -0400 Subject: [hpsdr] SOLD Munin amp kits for sale Message-ID: Both Munin amps kits have been spoken for, pending funds. Thanks for all the replies. Bruce N1RX -------------- next part -------------- An HTML attachment was scrubbed... URL: From getpri at t-online.de Sun Aug 31 23:24:58 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 01 Sep 2014 08:24:58 +0200 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: <5404113A.1000700@t-online.de> Hello Jae, wow, good to hear that you were successful so fast. I am interested in your experience to port everything into Ubuntu. I updated my system to Ubuntu 14.04 last week, but I am not very happy with my system as it seems to have some problems. I guess I have to start with a new OS from a CD instead of upgrading. As I am running a dual boot (win7/ubuntu) OS, it is always a problem loading one system from scratch, only. So, I am just in front of starting with HPSDR on linux and eager to get informations about all the pitfalls. 73, Georg DL2KP Am 31.08.2014 22:30, schrieb Jae Stutzman: > ***** High Performance Software Defined Radio Discussion List ***** > > > > After about 3 hours worth of work and a few workarounds, I made my > first QSO on 20 meters under Linux! > > I used MonoDevelop as the IDE for the C# KISS solution. I had to make > a couple of changes for the P/Invokes of the fftw3f library and some > of the Networking calls, which are still not implemented within the > Mono CLR. The performance is quite good, I'll compare it to my Windows > box to see the differences. > > Here is a link to a screenshot of how it looks: > http://imgur.com/AsJ4pSE. I'll document my changes and the > dependencies that I installed to make it work soon. > > Thanks everyone for the welcome and thanks to the authors of KISS > Konsole for making the porting easy :) > > > 73, > > Jae - K5JAE > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Internet: in progress ********************************************************************** IMPORTANTE/IMPORTANT CONFIDENCIAL/CONFIDENTIALITY Este mensaje ha sido elaborado ?nicamente para uso de la persona o entidad a la que es remitido, ya que puede contener informaci?n personal, confidencial y de acuerdo a ley no puede ser difundido. Si el lector de este mensaje no es el destinatario se?alado, o la persona responsable para entregar el mensaje a quien est? dirigido, advertimos que cualquier divulgaci?n, retransmisi?n o copia de esta comunicaci?n esta estrictamente prohibida. Si usted ha recibido esta comunicaci?n por error, por favor s?rvase informarlo de inmediato al remitente por correo electr?nico o tel?fono y borrar inmediatamente el mensaje original. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail kann vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ********************************************************************** --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From la2ni at online.no Fri Aug 1 00:26:03 2014 From: la2ni at online.no (Kjell Karlsen) Date: Fri, 01 Aug 2014 09:26:03 +0200 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: Congratulations Warren! 73, Kjell, LA2NI P? Fri, 01 Aug 2014 07:05:14 +0200, skrev Bill Tracey : > ***** High Performance Software Defined Radio Discussion List ***** > > From > http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, > NR0V, of Santa Cruz, California. Pratt was cited for his research > leading to the development of PureSignal, "an adaptive baseband > pre-distortion algorithm used to improve the linearity of amplifiers and > reduce intermodulation distortion products emitted by software-defined > transmitters." > > Congratulations Warren, and thanks for your excellent contributions! > > Bill (kd5tfd) > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > -- Sendt med Operas e-postklient: http://www.opera.com/mail/ 1406877963.0 From meijer.ha at home.nl Fri Aug 1 00:56:10 2014 From: meijer.ha at home.nl (H.A. Meijer) Date: Fri, 1 Aug 2014 09:56:10 +0200 (CEST) Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: <1644767958.114768.1406879772837.open-xchange@oxbe3.tb.mail.iss.local> An HTML attachment was scrubbed... URL: From w4yn at earthlink.net Fri Aug 1 04:38:50 2014 From: w4yn at earthlink.net (Tim ORourke) Date: Fri, 1 Aug 2014 07:38:50 -0400 (GMT-04:00) Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner Message-ID: <3589696.1406893130994.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> This is way cool, tnx for all the FB effort for a fantastic solution! Tim Tim O\Rourke W4YN at ARRL.Net Low Power Amateur Radio Rocks Member of Flying Pigs,ARCI,GQRP,RSGB,ARRL Life Member R/C Pilot (sort of) NRA Life Member NRA Certified Rifle, Pistol, Black Powder Instructor, Range Officer -----Original Message----- >From: Bill Tracey >Sent: Aug 1, 2014 1:05 AM >To: HPSDR list >Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner > >***** High Performance Software Defined Radio Discussion List ***** > > From >http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > > * The 2014 ARRL Technical Innovation Award went to Warren C. >Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his >research leading to the development of PureSignal, "an adaptive >baseband pre-distortion algorithm used to improve the linearity of >amplifiers and reduce intermodulation distortion products emitted by >software-defined transmitters." > >Congratulations Warren, and thanks for your excellent contributions! > >Bill (kd5tfd) > > >_______________________________________________ >HPSDR Discussion List >To post msg: hpsdr at openhpsdr.org >Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >HPSDR web page: http://openhpsdr.org >Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1406893130.0 From g3vbv at blueyonder.co.uk Fri Aug 1 05:02:31 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Fri, 01 Aug 2014 13:02:31 +0100 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: <53DB81D7.8000506@blueyonder.co.uk> Brilliant News! Absolutely! 73 ... Sid. On 01/08/14 06:05, Bill Tracey wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > From > http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > > * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, > NR0V, of Santa Cruz, California. Pratt was cited for his research > leading to the development of PureSignal, "an adaptive baseband > pre-distortion algorithm used to improve the linearity of amplifiers > and reduce intermodulation distortion products emitted by > software-defined transmitters." > > Congratulations Warren, and thanks for your excellent contributions! > > Bill (kd5tfd) > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > . > -- 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 1406894551.0 From abhiarunoday at gmail.com Fri Aug 1 07:06:25 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Fri, 1 Aug 2014 19:36:25 +0530 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner Message-ID: Congratulations Warren, well deserved, Please let me also add that it is a pleasure and an honor to work with Warren, Kudos!!!! Abhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From nealk3nc at gmail.com Fri Aug 1 07:58:12 2014 From: nealk3nc at gmail.com (Neal Campbell) Date: Fri, 1 Aug 2014 10:58:12 -0400 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: References: Message-ID: He is unbelievably talented as well as an incredibly smart dude! Add generous to that list also. Congrats Warren, I could not imagine a more worthy person. 73 Neal Campbell Abroham Neal LLC On Fri, Aug 1, 2014 at 10:06 AM, Abhi A wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > Congratulations Warren, well deserved, > > Please let me also add that it is a pleasure and an honor to work with > Warren, > > Kudos!!!! > > Abhi > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scotty at tonks.com Fri Aug 1 11:23:07 2014 From: scotty at tonks.com (Scott Cowling) Date: Fri, 01 Aug 2014 11:23:07 -0700 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com > References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: <7.0.1.0.2.20140801112159.04ddfcf0@tonks.com> Congratulations, Warren! Very well deserved! 73, Scotty WA2DFI At 00:05 2014-08-01 -0500, Bill Tracey wrote: >***** High Performance Software Defined Radio Discussion List ***** > > From > http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > > * The 2014 ARRL Technical Innovation Award went to Warren C. > Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his > research leading to the development of PureSignal, "an adaptive > baseband pre-distortion algorithm used to improve the linearity of > amplifiers and reduce intermodulation distortion products emitted > by software-defined transmitters." > >Congratulations Warren, and thanks for your excellent contributions! > >Bill (kd5tfd) 1406917387.0 From ve7mdl at gmail.com Fri Aug 1 12:03:33 2014 From: ve7mdl at gmail.com (Erik Skovgaard) Date: Fri, 1 Aug 2014 12:03:33 -0700 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: Congratulations Warren and thanks for all your hard work! 73 de ve7mdl, ....Erik. Currently marine mobile as ve0mdl On Jul 31, 2014 10:05 PM, "Bill Tracey" wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > From http://www.arrl.org/news/arrl-board-lauds-unforgettable- > milestone-formalizes-lotw-policy-honors-award-recipients > * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, > NR0V, of Santa Cruz, California. Pratt was cited for his research leading > to the development of PureSignal, "an adaptive baseband pre-distortion > algorithm used to improve the linearity of amplifiers and reduce > intermodulation distortion products emitted by software-defined > transmitters." > > Congratulations Warren, and thanks for your excellent contributions! > > Bill (kd5tfd) > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/ > listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beford at myfairpoint.net Fri Aug 1 12:43:56 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Fri, 1 Aug 2014 15:43:56 -0400 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Message-ID: Well deserved recognition for a remarkable advancement of the radio art. Congratulations. Bruce/N1RX 1406922236.0 From tfox at knology.net Fri Aug 1 16:40:59 2014 From: tfox at knology.net (Terry Fox) Date: Fri, 1 Aug 2014 19:40:59 -0400 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk><53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: I just got in from a day of antenna work, and saw this. Congratulations Warren!!! Your commitment to moving PureSignal forward, along with other SDR work, is impressive indeed!! Keep it up! 73, Terry, WB4JFI -----Original Message----- From: Bill Tracey Sent: Friday, August 01, 2014 1:05 AM To: HPSDR list Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner ***** High Performance Software Defined Radio Discussion List ***** From http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his research leading to the development of PureSignal, "an adaptive baseband pre-distortion algorithm used to improve the linearity of amplifiers and reduce intermodulation distortion products emitted by software-defined transmitters." Congratulations Warren, and thanks for your excellent contributions! Bill (kd5tfd) _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1406936459.0 From aa8k73 at gmail.com Fri Aug 1 21:24:26 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Sat, 02 Aug 2014 00:24:26 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/02 Message-ID: <53DC67FA.8060802@gmail.com> The 2/Aug TeamSpeak mp3 (67 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3509 > or < http://www.hamsdr.com/dnld.aspx > Session text follows <20:56:42> *** You are now talking in channel: "OpenHPSDR" <21:00:14> "Mike - AA8K": Congratulations Warren! <21:01:04> "Terry WB4JFI": Yes, Congratulations Warren!! Good work there! <21:01:51> "Warren - NR0V": Thanks very much. I enjoy the work and feel honored to be recognized. <21:24:05> "Mike - AA8K": Recordings: It's my way of contributing to the projects. :) <21:51:39> "Ken N9VV": Basic Configuration ? Tegra K1 SOC ? 2 Gbyte x16 memory with 64 bit width (can accommodate from 1-4 GByte total) ? 16GB 4.51 eMMC memory (footprint expandable from 16-256GByte memory) ? One empty half mini-PCIE slot with one USB and single lane PEX ? One SD/MMC connector ? One USB 2.0 port, micro AB ? One USB 3.0 port, type A ? HDMI port, type A ? TMP451 temperature monitor ? RS232 Serial port routed to UART4 ? ALC5639 Realtek Audio codec with separate MIC in and Line out jacks ? RTL8111GS Realtek GigE LAN/PHY with PEX interface ? One SATA data port ? SPI 4MByte Boot Flash device ? AMS AS3722 Power Management IC for power and sequencing ? Board ID EEPROM Signal Groups Routing to Expansion Headers ? DP / LVDS ? Touch SPI ? Camera_0 (one CSI differential data pair) & Camera_1 (four CSI differential data pairs) <21:51:46> "Ken N9VV": ? GPIO PU(6:0) general purpose IO ? UART ? HSIC ? GEN(2:1)_I2C, PWR_I2C, CAM_I2C ? Miscellaneous Power Connectors and Expansion Headers ? USB 2.0 OTG ? USB 3.0, flag configuration ? 2mm pitch Expansion headers (5x25 configuration) ? RJ45 ethernet with integrated gigabit magnetics ? HDMI type A port ? DSUB9 male serial port ? MIC-in, Headphone-out 3.5mm jacks ? JTAG 2x10 100 mil pitch THM (Through Hole Mount) ? DC power jack <21:52:37> "Rob - VE3EW": rob creswon rcrewson{AT}cinci.rr.com <21:52:53> "Rob - VE3EW": u can see i done type well <21:56:50> "Ken N9VV": Already announced Tablet last week <21:59:52> "Ken N9VV": July 23rd: < http://blogs.nvidia.com/blog/2014/07/23/why-shield-family/ > <22:01:11> "Ken N9VV": < http://www.androidheadlines.com/2014/07/nvidia-shield-tablet-now-available-299.html > <22:02:24> "Ken N9VV": Nvidia Shield Tablet for sale $299 from Amazon <22:06:51> "Ken N9VV": Lake Superior is 1,335 feet deep and 350 miles long. <22:07:05> "Ken N9VV": < http://en.wikipedia.org/wiki/Great_Lakes > <22:11:30> "Warren - NR0V": 73 ... time to go check with the XYL on the dinner plans 1406953466.0 From nu8i at cox.net Sat Aug 2 12:47:29 2014 From: nu8i at cox.net (Alfred Green) Date: Sat, 02 Aug 2014 12:47:29 -0700 Subject: [hpsdr] FM squelch Message-ID: <53DD4051.5010902@cox.net> Greetings, I'm currently using mRX PS v3.2.17 with a Hermes and homebrew transverters. I rarely operate FM, but a local station was active for the UHF contest with an FM rig on 1296, so I worked him for the point. However, the signal was pretty weak, although quite visible on the waterfall. I would have liked to have opened the squelch to assist with the copy, but setting SQL to zero didn't do the trick. I had to wait for the signal to get a good ways over the noise before the rx would open. I'm pretty sure this worked differently in an earlier release, but as I rarely do this I could be mistaken. Am I missing a setting, or is this performance to be expected? 73 Alf NU8I Phoenix AZ DM33xo 1407008849.0 From n9vv at wowway.com Sat Aug 2 13:50:40 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Sat, 02 Aug 2014 15:50:40 -0500 Subject: [hpsdr] FM squelch In-Reply-To: <53DD4051.5010902@cox.net> References: <53DD4051.5010902@cox.net> Message-ID: <53DD4F20.3020007@wowway.com> I am not sure that I can offer you a good explanation about this Alf, but you might want to use a calibrated signal source like the Elecraft XG-1 which emits a 50uv = S9 = -73db signal at 7040, and has another setting of -113db = S1 = ?uv with a switch. You can then know that your receiver is properly calibrated with any sort of input. I believe some of the more modern Elecraft calibrators allow you to select any frequency you wish. Perhaps you could substitute the calibrated signal for the IF signal coming from the transverter, and then adjust the SQUELCH on/off and level slider as needed to verify it's tripping levels in your setup. GL de Ken N9VV On 8/2/2014 2:47 PM, Alfred Green wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Greetings, > > I'm currently using mRX PS v3.2.17 with a Hermes and homebrew transverters. > > I rarely operate FM, but a local station was active for the UHF contest > with an FM rig on 1296, so I worked him for the point. > However, the signal was pretty weak, although quite visible on the > waterfall. I would have liked to have opened the squelch to assist with > the copy, but setting SQL to zero didn't do the trick. I had to wait for > the signal to get a good ways over the noise before the rx would open. > > I'm pretty sure this worked differently in an earlier release, but as I > rarely do this I could be mistaken. > > Am I missing a setting, or is this performance to be expected? > > 73 Alf NU8I > Phoenix AZ DM33xo > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1407012640.0 From nu8i at cox.net Sat Aug 2 16:34:44 2014 From: nu8i at cox.net (Alfred Green) Date: Sat, 02 Aug 2014 16:34:44 -0700 Subject: [hpsdr] FM squelch In-Reply-To: References: <53DD4051.5010902@cox.net> Message-ID: <53DD7594.8060509@cox.net> On 8/2/2014 1:50 PM, Ken N9VV (Win-7/64) wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I am not sure that I can offer you a good explanation about this Alf, > but you might want to use a calibrated signal source like the Elecraft > XG-1 which emits a 50uv = S9 = -73db signal at 7040, and has another > setting of -113db = S1 = ?uv with a switch. > > You can then know that your receiver is properly calibrated with any > sort of input. I believe some of the more modern Elecraft calibrators > allow you to select any frequency you wish. > > Perhaps you could substitute the calibrated signal for the IF signal > coming from the transverter, and then adjust the SQUELCH on/off and > level slider as needed to verify it's tripping levels in your setup. > Tnx for the comments, Ken. The IF is well calibrated; in fact I have good sources through 10Gigs so that is not the issue. When you mentioned "adjust the SQUELCH on/off and level slider" I had an 'ah-ha' moment; clicking on the 'SQL: xx' box turns on/off the squelch. I had forgotten that was a control, but it does exactly what I needed. Maybe I should just RTFM. GL & 73, Alf NU8I 1407022484.0 From warren at wpratt.com Sat Aug 2 19:22:37 2014 From: warren at wpratt.com (Warren C. Pratt) Date: Sat, 02 Aug 2014 19:22:37 -0700 Subject: [hpsdr] FM squelch In-Reply-To: <53DD7594.8060509@cox.net> References: <53DD4051.5010902@cox.net> <53DD7594.8060509@cox.net> Message-ID: <53DD9CED.4050900@wpratt.com> Hi Alf, I got out the FM signal generator and did a quick check. All here seems to be working as expected. Setting differences could be the issue. The thing to check first is the sample rate. Because of the bandwidths involved in FM demodulation and modulation, I would not recommend using less than a 192K sample rate for FM. DSP Buffer Size might also be relevant. At 192K, I'd use 4096. In any case, if you are still having difficulty, you've found the workaround for the moment -- the squelch OFF button. Let me know if sample rate / DSP buffer size helps. 73, Warren NR0V On 8/2/2014 4:34 PM, Alfred Green wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > On 8/2/2014 1:50 PM, Ken N9VV (Win-7/64) wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> I am not sure that I can offer you a good explanation about this Alf, >> but you might want to use a calibrated signal source like the >> Elecraft XG-1 which emits a 50uv = S9 = -73db signal at 7040, and has >> another setting of -113db = S1 = ?uv with a switch. >> >> You can then know that your receiver is properly calibrated with any >> sort of input. I believe some of the more modern Elecraft calibrators >> allow you to select any frequency you wish. >> >> Perhaps you could substitute the calibrated signal for the IF signal >> coming from the transverter, and then adjust the SQUELCH on/off and >> level slider as needed to verify it's tripping levels in your setup. >> > > Tnx for the comments, Ken. > The IF is well calibrated; in fact I have good sources through 10Gigs > so that is not the issue. > When you mentioned "adjust the SQUELCH on/off and level slider" I had > an 'ah-ha' moment; clicking on the 'SQL: xx' box turns on/off the > squelch. I had forgotten that was a control, but it does exactly what > I needed. > > Maybe I should just RTFM. > > GL & 73, Alf NU8I > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1407032557.0 From nu8i at cox.net Sun Aug 3 08:02:40 2014 From: nu8i at cox.net (Alfred Green) Date: Sun, 03 Aug 2014 08:02:40 -0700 Subject: [hpsdr] FM squelch In-Reply-To: References: <53DD4051.5010902@cox.net> <53DD7594.8060509@cox.net> Message-ID: <53DE4F10.3090503@cox.net> On 8/2/2014 7:22 PM, Warren C. Pratt wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Alf, > > I got out the FM signal generator and did a quick check. All here > seems to be working as expected. Setting differences could be the > issue. The thing to check first is the sample rate. Because of the > bandwidths involved in FM demodulation and modulation, I would not > recommend using less than a 192K sample rate for FM. DSP Buffer Size > might also be relevant. At 192K, I'd use 4096. > > In any case, if you are still having difficulty, you've found the > workaround for the moment -- the squelch OFF button. > > Let me know if sample rate / DSP buffer size helps. > Hello Warren, I appreciate the comments. I'm running at 48k sample rate with 2048 rx buffer size. If I change to 192k sr the squelch slider seems to operate more like I was expecting, ie. with no or little signal, setting squelch to 0 opens the Rx. That may be how I had it set before, so my old memory may not be failing. However, it really isn't an issue anymore, as I have found the on/off button. I have now had a whopping 2 contacts on FM in the last year or so; usually I am on CW/SSB/JT on UHF and up. It was just that a local had an FM HT with him that would work on 1296, so it was worth a shot for a point. If anyone is planning on using FM more seriously then the note about sample rate would be an important consideration. Tnx for everything. 73 Alf NU8I Phoenix AZ DM33xo 1407078160.0 From i7swx at yahoo.com Sun Aug 3 08:39:01 2014 From: i7swx at yahoo.com (Giancarlo Moda) Date: Sun, 3 Aug 2014 16:39:01 +0100 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner Message-ID: <1407080341.82109.YahooMailNeo@web172003.mail.ir2.yahoo.com> THE VERY BEST CONGRATULATIONS WARREN, this is the minimum we can say for the Aword you received and more for your "brain" contribution to the Ham and professional fields 73 Gian I7SWX Message: 3 Date: Fri, 01 Aug 2014 00:05:14 -0500 From: Bill Tracey To: HPSDR list Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical ??? Innovation Award winner Message-ID: ??? <201408010505.s71556Dv008606 at mail24c25-2209.carrierzone.com> Content-Type: text/plain; charset="us-ascii"; format=flowed From? http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients? ? ? * The 2014 ARRL Technical Innovation Award went to Warren C.? Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his? research leading to the development of PureSignal, "an adaptive? baseband pre-distortion algorithm used to improve the linearity of? amplifiers and reduce intermodulation distortion products emitted by? software-defined transmitters." Congratulations Warren, and thanks for your excellent contributions! Bill (kd5tfd) -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From getpri at t-online.de Mon Aug 4 05:18:57 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 04 Aug 2014 14:18:57 +0200 Subject: [hpsdr] PowerSDR and OZY In-Reply-To: <53DD9CED.4050900@wpratt.com> References: <53DD4051.5010902@cox.net> <53DD7594.8060509@cox.net> <53DD9CED.4050900@wpratt.com> Message-ID: <53DF7A31.4050102@t-online.de> Hello, what is the latest version of PowerSDR working with OZY? What are the appropriate firmware versions for Mercury and Penylane? 73, Georg, DL2KP --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com 1407154737.0 From vk5lb at yahoo.com.au Mon Aug 4 07:14:27 2014 From: vk5lb at yahoo.com.au (Dean) Date: Mon, 4 Aug 2014 23:44:27 +0930 Subject: [hpsdr] PwrSDR with Ozy Message-ID: Like Georg, there are many who are happy with Ozy, Mercury and Penelope running an old XP version of PwrSDR. I also would like to hear what people are running as far as XP versions of PwrSDR are concerned. I use 1.19.3.4 by W5WC and it is fine. Penelope 1.2 and Mercury 2.9 with single Rx. However is there a better choice? Cheers Dean. 1407161667.0 From getpri at t-online.de Mon Aug 4 07:44:14 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 04 Aug 2014 16:44:14 +0200 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: References: Message-ID: <53DF9C3E.8010709@t-online.de> Hi Dean, on my OZY-system, I am running OpenHPSDRmRX-FFT v3.2.1(12/23/13). The question is, if there are newer versions compatibel with OZY. I remember that somebody mentioned on this forum, that this should be the last version for OZY, but I am not shure. 73, Georg, dl2kp Am 04.08.2014 16:14, schrieb Dean: > ***** High Performance Software Defined Radio Discussion List ***** > > Like Georg, there are many who are happy with Ozy, Mercury and Penelope running an old XP version of PwrSDR. I also would like to hear what people are running as far as XP versions of PwrSDR are concerned. I use 1.19.3.4 by W5WC and it is fine. Penelope 1.2 and Mercury 2.9 with single Rx. However is there a better choice? > > Cheers Dean. > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- Internet: in progress ********************************************************************** IMPORTANTE/IMPORTANT CONFIDENCIAL/CONFIDENTIALITY Este mensaje ha sido elaborado ?nicamente para uso de la persona o entidad a la que es remitido, ya que puede contener informaci?n personal, confidencial y de acuerdo a ley no puede ser difundido. Si el lector de este mensaje no es el destinatario se?alado, o la persona responsable para entregar el mensaje a quien est? dirigido, advertimos que cualquier divulgaci?n, retransmisi?n o copia de esta comunicaci?n esta estrictamente prohibida. Si usted ha recibido esta comunicaci?n por error, por favor s?rvase informarlo de inmediato al remitente por correo electr?nico o tel?fono y borrar inmediatamente el mensaje original. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail kann vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ********************************************************************** --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com 1407163454.0 From ct1izu at sapo.pt Mon Aug 4 08:54:18 2014 From: ct1izu at sapo.pt (ct1izu) Date: Mon, 4 Aug 2014 16:54:18 +0100 Subject: [hpsdr] PwrSDR with Ozy References: Message-ID: <3C85201767F1422FBF481CBE40D6E427@dd52f851956584> Hi Dean My system at CT1IZU is OZY 2.1 Merc 3.1 Penny 1.6 used on a mini ITX D525 (1.8ghz) from Asus running an Nlited XP with SP2. works well but there are some issues on shutdown with it notnot saving data correctly. Shel CT1IZU 1407167658.0 From ct1izu at sapo.pt Mon Aug 4 08:58:42 2014 From: ct1izu at sapo.pt (ct1izu) Date: Mon, 4 Aug 2014 16:58:42 +0100 Subject: [hpsdr] PwrSDR with Ozy References: Message-ID: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> Dean Too much Vino Tinto Missed the important info pwr SDR Ver 3.2.9 2.23.14 Shel CT1IZU 1407167922.0 From k5so at valornet.com Mon Aug 4 09:38:47 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 4 Aug 2014 10:38:47 -0600 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> References: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> Message-ID: <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> All, Ozy is still being supported. Ozy works with the current versions of firmware and software on the OpenHPSDR download page (http://openhpsdr.org/download.php). In particular, the current official versions of firmware for Ozy based systems are: PowerSDR_mRX_PS_v3.2.17.0 Ozy v2.7 (included in the PowerSDR_mRX_PS_v3.2.17.0 folder and loads automatically when Ozy is selected as hardware and the initozy11.bat file is edited to point to Ozy_Janus.v27.rbf file) Mercury v3.4 Penelope v1.8 PureSignal is not implemented in any of the Atlas-based systems at the present time so that option in PowerSDR is not available when running Ozy (or Metis). Keep in mind that you may not mix ?old? firmware versions with firmware version that are later than 4May2013 (i.e., Ozy_Janus_v2.5 in the case for Ozy) as a major change for all the Atlas-based boards was made to implement a new I2C bus communications scheme between Ozy(or Metis) and the Mercury/Penelope boards. If you use a version of current firmware in any of the Ozy/Mercury/Penelope boards you must use current firmware in all of the boards (recommended). 73, Joe K5SO 1407170327.0 From getpri at t-online.de Mon Aug 4 10:32:59 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 04 Aug 2014 19:32:59 +0200 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> References: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> Message-ID: <53DFC3CB.1000502@t-online.de> Thank you Joe and all who responded. Best wishes and 73 Georg, DL2KP Am 04.08.2014 18:38, schrieb Joe Martin K5SO: > ***** High Performance Software Defined Radio Discussion List ***** > > > All, > > Ozy is still being supported. Ozy works with the current versions of firmware and software on the OpenHPSDR download page (http://openhpsdr.org/download.php). > > In particular, the current official versions of firmware for Ozy based systems are: > > PowerSDR_mRX_PS_v3.2.17.0 > > Ozy v2.7 (included in the PowerSDR_mRX_PS_v3.2.17.0 folder and loads automatically when Ozy is selected as hardware and the initozy11.bat file is edited to point to Ozy_Janus.v27.rbf file) > > Mercury v3.4 > > Penelope v1.8 > > PureSignal is not implemented in any of the Atlas-based systems at the present time so that option in PowerSDR is not available when running Ozy (or Metis). > > Keep in mind that you may not mix ?old? firmware versions with firmware version that are later than 4May2013 (i.e., Ozy_Janus_v2.5 in the case for Ozy) as a major change for all the Atlas-based boards was made to implement a new I2C bus communications scheme between Ozy(or Metis) and the Mercury/Penelope boards. > > If you use a version of current firmware in any of the Ozy/Mercury/Penelope boards you must use current firmware in all of the boards (recommended). > > 73, Joe K5SO > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- Internet: in progress ********************************************************************** IMPORTANTE/IMPORTANT CONFIDENCIAL/CONFIDENTIALITY Este mensaje ha sido elaborado ?nicamente para uso de la persona o entidad a la que es remitido, ya que puede contener informaci?n personal, confidencial y de acuerdo a ley no puede ser difundido. Si el lector de este mensaje no es el destinatario se?alado, o la persona responsable para entregar el mensaje a quien est? dirigido, advertimos que cualquier divulgaci?n, retransmisi?n o copia de esta comunicaci?n esta estrictamente prohibida. Si usted ha recibido esta comunicaci?n por error, por favor s?rvase informarlo de inmediato al remitente por correo electr?nico o tel?fono y borrar inmediatamente el mensaje original. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail kann vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ********************************************************************** --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com 1407173579.0 From wb4gcs at wb4gcs.org Mon Aug 4 15:02:02 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Mon, 04 Aug 2014 18:02:02 -0400 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> References: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> Message-ID: <53E002DA.1080004@wb4gcs.org> Joe: I'm a bit confused by the "keep in mind" paragraph. Does this mean there is some hardware version at which the firmware splits? I have an atlas/ozy/janus system that is probably near original hardware from TAPR. Will the latest firmware you mention below run on that system, or is there some version at which that hardware is no longer supported? Thanks & 73, Jim wb4gcs at amsat.org On 8/4/2014 12:38 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > All, > > Ozy is still being supported. Ozy works with the current versions of firmware and software on the OpenHPSDR download page (http://openhpsdr.org/download.php). > > In particular, the current official versions of firmware for Ozy based systems are: > > PowerSDR_mRX_PS_v3.2.17.0 > > Ozy v2.7 (included in the PowerSDR_mRX_PS_v3.2.17.0 folder and loads automatically when Ozy is selected as hardware and the initozy11.bat file is edited to point to Ozy_Janus.v27.rbf file) > > Mercury v3.4 > > Penelope v1.8 > > PureSignal is not implemented in any of the Atlas-based systems at the present time so that option in PowerSDR is not available when running Ozy (or Metis). > > Keep in mind that you may not mix ?old? firmware versions with firmware version that are later than 4May2013 (i.e., Ozy_Janus_v2.5 in the case for Ozy) as a major change for all the Atlas-based boards was made to implement a new I2C bus communications scheme between Ozy(or Metis) and the Mercury/Penelope boards. > > If you use a version of current firmware in any of the Ozy/Mercury/Penelope boards you must use current firmware in all of the boards (recommended). > > 73, Joe K5SO > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1407189722.0 From beford at myfairpoint.net Mon Aug 4 17:31:08 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Mon, 4 Aug 2014 20:31:08 -0400 Subject: [hpsdr] PwrSDR with Ozy Message-ID: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> Jim- The have been no changes in the hardware. Joe's reminder is that if you are using firmware later than 4May13 in one board, you must use firmware later than that date in ALL the boards on the system. This is because some signals were redefined at that time. The hardware hasn't changed, but the purpose of some of the various signal pins did (defined by the firmware, not the hardware). So- don't mix old board firmware and newer firmware in an Atlas-based system. I hope this helps. Bruce/N1RX > Joe: > I'm a bit confused by the "keep in mind" paragraph. Does this mean > there is some hardware version at which the firmware splits? 1407198668.0 From k5so at valornet.com Mon Aug 4 17:39:01 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 4 Aug 2014 18:39:01 -0600 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> References: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> Message-ID: -ditto. Thanks Bruce, I was out today. 73, Joe K5SO On Aug 4, 2014, at 6:31 PM, Bruce Beford wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Jim- > The have been no changes in the hardware. Joe's reminder is that if you are > using firmware later than 4May13 in one board, you must use firmware later > than that date in ALL the boards on the system. This is because some signals > were redefined at that time. The hardware hasn't changed, but the purpose of > some of the various signal pins did (defined by the firmware, not the > hardware). So- don't mix old board firmware and newer firmware in an > Atlas-based system. > I hope this helps. > Bruce/N1RX > >> Joe: >> I'm a bit confused by the "keep in mind" paragraph. Does this mean >> there is some hardware version at which the firmware splits? > > 1407199141.0 From wb4gcs at wb4gcs.org Mon Aug 4 18:10:53 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Mon, 04 Aug 2014 21:10:53 -0400 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: References: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> Message-ID: <53E02F1D.1070505@wb4gcs.org> Bruce & Joe: Got it, thanks! FYI, I intend to use Janus/Ozy with a 2-slot Atlas I picked up somewhere to interface to a UHFSDR, which is the IF for my microwave stack: 222, 903,1293, 2304, 3446, 5763 and 10368. The last two will be double-conversion to obey the IF >= 0.1 RF rule. 73, Jim wb4gcs at amsat.org On 8/4/2014 8:39 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > -ditto. Thanks Bruce, I was out today. > > 73, Joe K5SO > > On Aug 4, 2014, at 6:31 PM, Bruce Beford wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Jim- >> The have been no changes in the hardware. Joe's reminder is that if you are >> using firmware later than 4May13 in one board, you must use firmware later >> than that date in ALL the boards on the system. This is because some signals >> were redefined at that time. The hardware hasn't changed, but the purpose of >> some of the various signal pins did (defined by the firmware, not the >> hardware). So- don't mix old board firmware and newer firmware in an >> Atlas-based system. >> I hope this helps. >> Bruce/N1RX >> >>> Joe: >>> I'm a bit confused by the "keep in mind" paragraph. Does this mean >>> there is some hardware version at which the firmware splits? >> > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1407201053.0 From carcia at sbcglobal.net Tue Aug 5 08:26:00 2014 From: carcia at sbcglobal.net (FRANCIS CARCIA) Date: Tue, 5 Aug 2014 08:26:00 -0700 Subject: [hpsdr] IMD Message-ID: <1407252360.20359.YahooMailNeo@web184705.mail.ne1.yahoo.com> Hi All, ?As a suffering Giants football fan and a long time chaser of the IMD monster. Congradulations Warren. I will be starting metal work on my QRO SS linear soon now that my slabs of copper have returned from the machine shop. Great Job. Frank WA1GFZ -------------- next part -------------- An HTML attachment was scrubbed... URL: From k2ue at rochester.rr.com Thu Aug 7 15:42:19 2014 From: k2ue at rochester.rr.com (Clyde Washburn) Date: Thu, 7 Aug 2014 18:42:19 -0400 Subject: [hpsdr] Remote Control? Message-ID: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> What is the state of the art in remote control of an OpenHPSDR Tranceiver (such as an Anan) via an internet connection with 1 or 2Mb/s uplink and typical latency? I know OpenHPSDR can be operated via Remote Desktop, but what is the optimal setup for Rx audio to the remote site and Tx audio to the Transceiver, i.e. a full, functioning remote setup? ___________________ Clyde Washburn, K2UE k2ue at ieee.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From n9vv at wowway.com Thu Aug 7 16:11:24 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Thu, 07 Aug 2014 18:11:24 -0500 Subject: [hpsdr] Remote Control? In-Reply-To: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> References: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> Message-ID: <53E4079C.1040203@wowway.com> Hi Clyde, I think the optimal (consultant) answer will cost more than your whole station :-) Here is a list of REMOTE CONTROL programs that are popular. Each claims to be the best. Some have full Audio support: ---------------------------------------------- http://www.remotehams.com/ Any Desk SplashTOP Screen Hero Google Remote Teamviewer Mikogo Parallels Access http://www.dxzone.com/catalog/Contesting/Stations/ (50 entries) http://www.dxzone.com/catalog/Manufacturers/Remote_Control/ (5) http://www.dxzone.com/catalog/Operating_Modes/Remote_Operations/ (9) http://www.dxzone.com/dx6349/internet-remote-base-society.html http://www.dxzone.com/dx13063/remote-controlled-hf-operations.html http://www.dxzone.com/dx24426/remoterig.html UltraVNC TightVNC TinyVNC Skype (for audio) ipSound (discontinued in 2006, but still popular) HPSDR (Android application for Internet Remote for OpenHPSDR written by G0ORX/N6LYT) QtRadio (Win/Lin/MAC remote application for OpenHPSDR written by G0ORX/N6LYT) glSDR - Android QtRadio client with full control written by volunteers for OpenHPSDR ---------------------------------------------- George, K5RIG, and I are currently testing each of these programs to see if any one of them might be suitable. Remote Control of a PC seems to be a very popular topic - and one that has *NOT* been resolved into a manageable set of alternatives. The fellows at RemoteHams.COM have a very attractive setup. So do a dozen others, all at varying prices and kinds of rigs. Flex Radio Systems is going to put Remote Operation on the top of their Developers list this year. They took a show of hands at their Dayton-2014 Banquet and *Remote Operation* was at the top of the list of desired features that their 6000 owners desired. So there is a good list of resources and you can begin your award winning book about "Remote Ham Radio Station Operation" -- or has the ARRL already done that? (hihihi). GL de Ken N9VV On 8/7/2014 5:42 PM, Clyde Washburn wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > What is the state of the art in remote control of an OpenHPSDR > Tranceiver (such as an Anan) via an internet connection with 1 or 2Mb/s > uplink and typical latency? I know OpenHPSDR can be operated via Remote > Desktop, but what is the optimal setup for Rx audio to the remote site > and Tx audio to the Transceiver, i.e. a full, functioning remote setup? > > ___________________ > > Clyde Washburn, K2UE > > k2ue at ieee.org > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1407453084.0 From aa8k73 at gmail.com Thu Aug 7 17:14:16 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Thu, 07 Aug 2014 20:14:16 -0400 Subject: [hpsdr] Remote Control? In-Reply-To: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> References: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> Message-ID: <53E41658.9060607@gmail.com> I don't believe that you will be able to transmit CW remotely in the future Clyde. From what I have gleaned about the Generation 2 HPSDR hardware, the telegraph key will be connected to the FPGA on the transmitter board itself as an effort to reduce latency. This is useful if you are physically near the transmitter, but if you have Repetitive Strain Injury ("glass arm") or another disability requiring you use a keyboard instead of wiggling a lever, or want to operate remotely, or to use any type of CW transmitting software, I'm guessing that you would need to tinker some sort of RS-232 type of kludge. On 14-08-07 06:42 PM, Clyde Washburn wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > What is the state of the art in remote control of an OpenHPSDR > Tranceiver (such as an Anan) via an internet connection with 1 > or 2Mb/s uplink and typical latency? I know OpenHPSDR can be > operated via Remote Desktop, but what is the optimal setup for > Rx audio to the remote site and Tx audio to the Transceiver, > i.e. a full, functioning remote setup? > > ___________________ > > Clyde Washburn, K2UE > > k2ue at ieee.org > 1407456856.0 From pa0tbr at mubo.nl Sat Aug 2 13:56:17 2014 From: pa0tbr at mubo.nl (Ton PA0TBR) Date: Sat, 2 Aug 2014 22:56:17 +0200 Subject: [hpsdr] Compile environement for PowerSDR_HPSDR_mRX_PS Message-ID: Hello, Is Visual Studio 2010 Express the correct environment to compile PowerSDR_HPSDR_mRX_PS? Are there any development notes available? 73, Ton PA0TBR -------------- next part -------------- An HTML attachment was scrubbed... URL: From vk5lb at yahoo.com.au Fri Aug 8 07:46:10 2014 From: vk5lb at yahoo.com.au (Dean PROBERT) Date: Fri, 8 Aug 2014 07:46:10 -0700 Subject: [hpsdr] Downloading Mercury 3.4 In-Reply-To: Message-ID: <1407509170.73138.YahooMailBasic@web120405.mail.ne1.yahoo.com> Thanks for the info I successfully downloaded all files listed below except Mercury V3,4, All I saw was the raw code. How can I download the file? ???????????? 1407509170.0 From jeffrie at talktalk.net Fri Aug 8 08:42:28 2014 From: jeffrie at talktalk.net (Jeff Cook) Date: Fri, 8 Aug 2014 16:42:28 +0100 Subject: [hpsdr] Downloading Mercury 3.4 Message-ID: <000001cfb31f$5d4736e0$17d5a4a0$@talktalk.net> Dean, try http://svn.tapr.org/repos_sdr_hpsdr/trunk/Mercury/Source/Mercury_V3.4/ Jeff, G0AFQ. -------------- next part -------------- An HTML attachment was scrubbed... URL: From k2xx at swva.net Fri Aug 8 14:19:01 2014 From: k2xx at swva.net (Joe Giacobello, K2XX) Date: Fri, 08 Aug 2014 17:19:01 -0400 Subject: [hpsdr] Hermes Breakout Brd 2-pin Header Message-ID: <53E53EC5.60209@swva.net> In procrastinating my assembly of the breakout board, I seemed to have lost one of the 2-pin PCB headers. If someone has a spare and can put it in an envelope and mail to my CBA, I'd be happy to reimburse by PayPal or whatever payment method works. Thanks for your help. 73, Joe K2XX 1407532741.0 From aa8k73 at gmail.com Fri Aug 8 20:33:06 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 08 Aug 2014 23:33:06 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/09 Message-ID: <53E59672.6040100@gmail.com> The 9/Aug TeamSpeak mp3 (51 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3510 > or < http://www.hamsdr.com/dnld.aspx > Session text follows <20:41:19> *** You are now talking in channel: "OpenHPSDR" <21:03:28> "Ken N9VV": Nvida Jetson TK1 - Xwindows remote to Windows PC: https://www.youtube.com/watch?v=Z64z_R7MSMU <21:11:12> "Bill - KD5TFD": Yes yes .. TAPR DCC beginning of Sept <21:15:52> "Rick - VE3MM": Rob, Here is the digikey part number for the Hermes extension cable 'A3AKB-1018G-ND'. <21:16:42> "Bill - KD5TFD": AQRP charts on STM32F4 based sdr: https://dl.dropboxusercontent.com/u/14377548/2014%20SummerFest_1.pdf <21:17:04> "Bill - KD5TFD": and: http://stm32-sdr.com/ <21:17:28> "Rob - VE3EW": thanks Rick <21:20:41> "Phil-VK6PH": http://www.ab4oj.com/sdr/apache/anan100d200d_notes.pdf <21:20:45> "Bill - KD5TFD": works ok here <21:21:11> "Ken N9VV": http://www.ab4oj.com/sdr/apache/anan100d200d_notes.pdf FB Here <21:21:38> "Bill - KD5TFD": IE? <21:21:39> "Bill - KD5TFD": IE? <21:21:46> "Bill - KD5TFD": Use a real real browser1 <21:21:49> "Bill - KD5TFD": Use a real real browser! <21:26:37> "Ken N9VV": God! that Keying Envelope looks *GREAT* <21:42:05> "Rick - VE3MM": 73 guys see you next week <21:45:38> "Bill - KD5TFD": sarcasm <22:07:16> "Bill - KD5TFD": so do macs <22:07:20> "Bill - KD5TFD": and linuii's <22:08:02> "Bill - KD5TFD": never do the fix my pc stuff imho 1407555186.0 From vk6vz at arach.net.au Sat Aug 9 07:42:26 2014 From: vk6vz at arach.net.au (Steve Ireland) Date: Sat, 9 Aug 2014 22:42:26 +0800 Subject: [hpsdr] For Sale: Munin PA kit and Tmate 2 USB SDR Control Console Message-ID: <4F58396271064EC8B49A5020427EA8F8@StevesHPpcPC> G?day I have for sale an HPSDR Munin Power Amplifier kit compiled by Don K3DLW and a WoodBox Radio Tmate2 USB SDR Control Console in ?as new? condition. The Tmate2 has been used with OpenHPSDR W5WC v2.2.12 and all its functionality was available with this software except for the wattmeter. The Munin Power Amplifier Kit is for sale at $200 Australian and has not been opened. The WoodBox Radio Tmate2 is 15 months old, cost 260 Euros (approx. $375 Australian) and is for sale at $300 Australian. Postage on both items will be extra. If you are interested in either item, please email me. Thank you. Vy 73 Steve, VK6VZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ad0es at ad0es.net Sat Aug 9 08:26:15 2014 From: ad0es at ad0es.net (AD0ES) Date: Sat, 9 Aug 2014 09:26:15 -0600 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: Message-ID: Hi, I wrote earlier about my issues getting a metis/mercury working. Finally had success last nite! For the record, I found the following: The mercury as shipped from TAPR had unknown/non-working firmware installed: > Mercury Software version: 255 (0xFF) I upgraded metis to 2.9 and mercury to 3.4. I tried 4 different software packages, only one works. Each was built from sources obtained from their motherload several weeks ago: ghpsdr: seg-faults on startup. ghpsdr3: works. ghpsdr3-Qt: dspserver seg-faults on startup. ghpsdr3-alex: runs, but is "deaf" <<< this was the version I did most of my early testing with Using ubuntu 64-bit 14.04.1 I am going after the seg-faults next, any wisdom on this issue gladly accepted... Steve AD0ES On Jul 23, 2014, at 9:47 AM, AD0ES wrote: > Using ghpsdr3-alex. > > ------------------- > Start hpsdr-server: > /usr/local/bin/hpsdr-server --metis --interface eth0 --10mhzsource mercury --122.88mhzsource mercury > > ... > > Mercury Software version: 255 (0xFF) 1407597975.0 From k2xx at swva.net Sat Aug 9 08:46:07 2014 From: k2xx at swva.net (Joe Giacobello, K2XX) Date: Sat, 09 Aug 2014 11:46:07 -0400 Subject: [hpsdr] Hermes Breakout Brd 2-pin Header (Got it!) Message-ID: <53E6423F.90801@swva.net> K6GGO kindly offered to send me the part. Many thanks, Joe K2XX In procrastinating my assembly of the breakout board, I seemed to have lost one of the 2-pin PCB headers. If someone has a spare and can put it in an envelope and mail to my CBA, I'd be happy to reimburse by PayPal or whatever payment method works. Thanks for your help. 73, Joe K2XX 1407599167.0 From cmwalker at mweb.co.za Sat Aug 9 21:40:10 2014 From: cmwalker at mweb.co.za (Conrad Walker) Date: Sun, 10 Aug 2014 06:40:10 +0200 Subject: [hpsdr] PowerSDR & OZY/Mercury/Penelope updating Message-ID: <002c01cfb455$2c0e2ca0$842a85e0$@co.za> Hello all I decided to update my Ozy/Mercury/Penelope HPSDR on WinXP to v2.7/v3.4/v1.8 with PowerSDR v3.2.17.0. Try as I might, I could not flash Mercury with v3.4 firmware via Ozy with USB-Blaster & either Quartus 9.1, 10.1, 12.1 or 13.0. Quartus 9.10 &10.1 gave an error "file Mercury-v3.4.jic corrupted" - unknown argument "Mercury-3.4.cdf", refer to help for legal arguments. Quartus 12.1 and 13.0 gave a "device not ready" error. I was able to flash Mercury v3.3 with Quartus 9.1 & 10.1, and all Quartus versions successfully flashed Penelope v1.8. I was able to run PowerSDR v3.2.17.0 with Mercury v3.3 and Penny v1.7 but found that the CW setup option to use Ozy/Hermes for CW keying no longer exists, and so can no longer run CW with my present setup, My earlier PowerSDR installation worked fine. Any ideas on sorting this out would be most appreciated. 73, Conrad Walker ZS6BQQ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.montefusco at gmail.com Sun Aug 10 11:03:11 2014 From: andrea.montefusco at gmail.com (andrea montefusco) Date: Sun, 10 Aug 2014 20:03:11 +0200 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> Message-ID: On Sun, Aug 10, 2014 at 3:57 PM, AD0ES wrote: > I am aware of cuSDR, but a quick google didn't find the motherload for linux src, any links? As per http://openhpsdr.org/download.php the source are foud in http://svn.tapr.org/repos_sdr_hpsdr/trunk/DL3HVH/cuSDR64/ it requires Qt 4.8. 1407693791.0 From lu9cbl at gmail.com Sun Aug 10 11:16:00 2014 From: lu9cbl at gmail.com (lu9cbl at gmail.com) Date: Sun, 10 Aug 2014 15:16:00 -0300 Subject: [hpsdr] Starting with HPSDR from Argentina Message-ID: <53E7B6E0.30606@gmail.com> Hi to all... if i want to start with HPSDR, only with the "Atlas Bus", "Mercury Receiver" and the filters "Alex RX" can it works?? or i?m need another "module" for example "Comunication (Ozy, Magister, Metis)"??? Here in Argentina it?s very difficult to buy international ?tems, because we have several filters for import materials... so maybe i can buy the PCBs and make the boards with local components, or buy only the important componentes. I Have a friend that will be going to USA the next month, so he can bring it to me in his briefcase. Thanks in Advance and sorry for my poor english, i hope you can undesrtand me. Mati LU9CBL --- Este mensaje no contiene virus ni malware porque la protecci?n de avast! Antivirus est? activa. http://www.avast.com 1407694560.0 From wulf at ping.net.au Sun Aug 10 15:16:09 2014 From: wulf at ping.net.au (Berndt Josef Wulf) Date: Mon, 11 Aug 2014 07:46:09 +0930 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> Message-ID: <1407708969.5462.23.camel@Barossa> G'day, A modified version of cuSDR can be downloaded from http://www.ping.net.au/20140126_cuSDR64src.tar.gz It requires QT5 and may not work with the current firmware change, so your mileage may wary. 73, Berndt VK5ABN On Sun, 2014-08-10 at 20:03 +0200, andrea montefusco wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > On Sun, Aug 10, 2014 at 3:57 PM, AD0ES wrote: > > I am aware of cuSDR, but a quick google didn't find the motherload for linux src, any links? > > As per http://openhpsdr.org/download.php the source are foud in > > http://svn.tapr.org/repos_sdr_hpsdr/trunk/DL3HVH/cuSDR64/ > > it requires Qt 4.8. > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1407708969.0 From k5so at valornet.com Sun Aug 10 17:52:18 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 10 Aug 2014 18:52:18 -0600 Subject: [hpsdr] Starting with HPSDR from Argentina In-Reply-To: <53E7B6E0.30606@gmail.com> References: <53E7B6E0.30606@gmail.com> Message-ID: <7FC10CDE-148A-426A-AE9C-7935A4EB8C25@valornet.com> Your English is fine, Mati; no problem. Congratulations on thinking of putting together an Atlas-based HPSDR system. In addition to the Atlas bus, Mercury board, and Alex RX filter you will need a board to communicate with your computer; a Metis (ethernet) board or an Ozy (USB) or a Magister (USB); only one of those three computer comm boards, not all three. I recommend Metis, personally, as the ethernet connection is much superior to the USB methods, especially for high data rates that are necessary for wide bandwidths, but Ozy or Magister will work if you decide to use one of them instead. Also, if you use only the Alex RX filter you will have only high pass filtering on your receiver. If you wish to have bandpass filtering you will also need to use the Alex TX filter with the Alex RX filter. The Alex TX filter board provides low pass filtering. Together the Alex RX and Alex TX provide bandpass filtering. Of course, you can run simply a Mercury receiver and a Metis (or Ozy or Magister) on your Atlas bus to have a functional RX radio, without any Alex filters at all, if you wish to try that configuration first before purchasing Alex filter boards. The Alex filters are excellent filter boards and certainly enhance the operations, especially if you are in a location with large out-of-band signals present. I use both TX and RX Alex filters here and find them to be extremely useful to keep from overloading the Mercury receiver when large out-of-band signals are present. Good luck! 73, Joe K5SO On Aug 10, 2014, at 12:16 PM, lu9cbl at gmail.com wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi to all... if i want to start with HPSDR, only with the "Atlas Bus", "Mercury Receiver" and the filters "Alex RX" can it works?? or i?m need another "module" for example "Comunication (Ozy, Magister, Metis)"??? > > Here in Argentina it?s very difficult to buy international ?tems, because we have several filters for import materials... so maybe i can buy the PCBs and make the boards with local components, or buy only the important componentes. I Have a friend that will be going to USA the next month, so he can bring it to me in his briefcase. > > Thanks in Advance and sorry for my poor english, i hope you can undesrtand me. > Mati LU9CBL > > --- > Este mensaje no contiene virus ni malware porque la protecci?n de avast! Antivirus est? activa. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1407718338.0 From douglas.adams at me.com Mon Aug 11 04:45:39 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 07:45:39 -0400 Subject: [hpsdr] Radio (Board) Identification Message-ID: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> I would like to propose a small change to the firmware of all of the OpenHPSDR-derived radios. The purpose of this change would be to make the firmware update process more automatic and foolproof. If you look in Metis- How it works_V1.31 you will see that the Discovery packet returns the following: The payload of the UDP/IP reply frame is as follows: <0xEFFE>< Metis MAC Address><49 bytes of 0x00> where Board_ID = 1 byte, 0x00 = Metis, 0x01 = Hermes, 0x02 = Griffin, 0x04 = Angelia, 0x05 = Orion Currently the Board_ID field (one byte) is not very informative. If it says I have a Hermes (0x01) is it a TAPR Hermes, an ANAN-100, an ANAN-100B, an ANAN-100D, etc. Couldn't we use the 8 bits (256 possibilities) in this field to be more specific about the radio? Perhaps to be backward compatible we could reserve the least significant 4 bits for Board ID and use the most significant four bits for a Sub ID indicating which variant of the Board ID is present. If we coupled this change with a "gentlemen's agreement" to name all firmware files in some recognizable way, something like RadioName_vN.M.rbf ( e.g. ANAN100B_v2.4.rbf ) then it would be possible to write a programmer application that would only show you firmware choices appropriate for the radio you are trying to program. The current arrangement seems uninformative and error prone. 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From ad0es at ad0es.net Mon Aug 11 06:33:44 2014 From: ad0es at ad0es.net (AD0ES) Date: Mon, 11 Aug 2014 07:33:44 -0600 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: Message-ID: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> Hi, Using --hermes instead of --metis does indeed cure the deafness, thanx! So for the record, at this point all 4 programs are working: ghpsdr ghpsdr3 ghpsdr3-Qt ghpsdr3-alex Note that I had to make minor changes to get several of them to compile under Ubuntu 14.04.1 (trusty). Mostly issues of header file locations being moved since the last distro. Steve AD0ES On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES wrote: > >> ghpsdr3-alex: runs, but is "deaf" <<< this was the version I did most of my early testing with > > Steve, > please start the hpsdr-server with --hermes instead of --metis and > report if this cure the issue. 1407764024.0 From kb3omm at gmail.com Mon Aug 11 07:02:59 2014 From: kb3omm at gmail.com (kb3omm) Date: Mon, 11 Aug 2014 10:02:59 -0400 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> Message-ID: Steve, This is great news. Could you email out the changes you made to get each of the programs to build and run, to aid those like myself who cant program but can follow instructions. I have tried previously to get John's three programs to build on newer versions of Qt and Linux without success. Though, ghpsdr3-alex and cuSDR run fine and use them every day. Hermes, Mint 16, Qt4 and 5 73, Kevin On Mon, Aug 11, 2014 at 9:33 AM, AD0ES wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi, > > Using --hermes instead of --metis does indeed cure the deafness, thanx! > > So for the record, at this point all 4 programs are working: > ghpsdr > ghpsdr3 > ghpsdr3-Qt > ghpsdr3-alex > > Note that I had to make minor changes to get several of them to compile > under Ubuntu 14.04.1 (trusty). Mostly issues > of header file locations being moved since the last distro. > > Steve AD0ES > > On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: > > > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES wrote: > > > >> ghpsdr3-alex: runs, but is "deaf" <<< this was the version I > did most of my early testing with > > > > Steve, > > please start the hpsdr-server with --hermes instead of --metis and > > report if this cure the issue. > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 07:12:51 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 08:12:51 -0600 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> Message-ID: <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> Hi Doug, Interesting proposal that deserves some thought. I don?t disagree that our present system is not a perfect arrangement. Keep in mind however that the Board ID is not the only ID parameter ID that is passed in the packets, the actual firmware version is also passed in the packets in a different byte, so that in itself gives more information than you imply, I believe. The board ID is currently used, among other uses perhaps, by the HPSDR Programmer to determine how long to make the time out limit for the EEPROM erase process; some FPGAs are small (e.g., Metis, Mercury, Penny(Lane), Hermes) and erase quickly compared to the larger (Angelia and Orion) FPGAs that take a while to erase. Dave KV0S didn?t think (and I agree) that it was necessary, nor beneficial, to use a long time out delay for erasing FPGAs that didn?t need one. The current ID method works fine for that purpose and needs no additional expansion. While I certainly appreciate that we might want to specify which specific board type is in use (which we do already in a general sense with the current coarse board ID value) the firmware is used in many cases in a variety of hardware configurations of the same board type so it would not be possible for the firmware developer to write the more detailed ID number into the firmware without knowing ahead of time which of the several configurations for the board type is going to be used with the firmware. In the case of Angelia, as one example, the firmware can be used in any radio that uses the Angelia board such as the ANAN-100D or a barefoot Angelia, or an Angelia with an external PA, or with an Angelia with Alex filters, etc. In your suggestion it would seem that all of those different configurations should ideally have a different board ID value written into the firmware. The firmware design would be identical for those units but your suggested approach would seek to use a different board ?ID? for each of them depending upon how the user wanted to use the Angelia board, which the firmware writer would not know. Having a different board ID for each possible board configuration, and thus a different firmware version for each possible configuration, would lead to many versions of Angelia (etc) firmware for a given firmware design needing to be posted for each release and that in itself would undoubtedly prove to be confusing to the users, in my opinion. I haven?t thought through your suggestion completely but these points came immediately to my mind upon reading your message. Maybe others have comments and suggestions that are constructive for this discussion. Thanks for your thoughts on how we might improve things! Perhaps you have already thought through how to address issues such as these. I?m all for whatever makes the mose sense! 73, Joe K5SO On Aug 11, 2014, at 5:45 AM, Doug Adams wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I would like to propose a small change to the firmware of all of the OpenHPSDR-derived radios. The purpose of this change would be to make the firmware update process more automatic and foolproof. > > If you look in Metis- How it works_V1.31 you will see that the Discovery packet returns the following: > The payload of the UDP/IP reply frame is as follows: > <0xEFFE>< Metis MAC Address><49 bytes of 0x00> > > where > > Board_ID = 1 byte, 0x00 = Metis, 0x01 = Hermes, 0x02 = Griffin, 0x04 = Angelia, 0x05 = Orion > > Currently the Board_ID field (one byte) is not very informative. If it says I have a Hermes (0x01) is it a TAPR Hermes, an ANAN-100, an ANAN-100B, an ANAN-100D, etc. Couldn't we use the 8 bits (256 possibilities) in this field to be more specific about the radio? > > Perhaps to be backward compatible we could reserve the least significant 4 bits for Board ID and use the most significant four bits for a Sub ID indicating which variant of the Board ID is present. > > If we coupled this change with a "gentlemen's agreement" to name all firmware files in some recognizable way, something like RadioName_vN.M.rbf ( e.g. ANAN100B_v2.4.rbf ) then it would be possible to write a programmer application that would only show you firmware choices appropriate for the radio you are trying to program. > > The current arrangement seems uninformative and error prone. > > 73?s > Doug - K3TZR > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wully at bluewin.ch Mon Aug 11 09:03:01 2014 From: wully at bluewin.ch (wully) Date: Mon, 11 Aug 2014 18:03:01 +0200 Subject: [hpsdr] CC-Byte0 from fpga to pc Message-ID: <53E8E935.4090808@bluewin.ch> Hi In the Comand-and-Control-Byte 0 from FPGA to PC there are 3 Bits PTT, Dash and Dot. I would like to use at least one of these bits to control an activity. But I don't know, how these bits are fed. From the schematics of METIS and fpga-code I think that Pins 6,7 and 8 on the DB9 connector should be mapped to these (debounced) Bits, but grounding these does not show an effect on the CC-Byte 0. Hardware: Metis (fpga V2.1) Penelope (fpga 1.7) Mercury (fpga 3.3) 1) Which hardware- bits control the Bits 0..2 of CCbyte0 when using the above hardware? 2) Which hardware- bits control if I use Magister instead of Metis (IN0, IN1 and IN2 are also present there). Thank you for your information. 73, hb9epu 1407772981.0 From g3vbv at blueyonder.co.uk Mon Aug 11 09:07:25 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 11 Aug 2014 17:07:25 +0100 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> Message-ID: <53E8EA3D.9060807@blueyonder.co.uk> I modified GHPSDR3-Qt/FULL/KV0S/KV0S.pro, adding the Qt include PATHS INCLUDEPATH += . \ /usr/include/QtMultimedia /usr/include/QtNetwork /usr/include/QtXml \ ghpsdr3/DRadio \ griffin/griffinID \ Missing file frequencysender.h:- IQt-Radio-Programs/QtHPSDRServer/client -I. -I. -o receivethread.o hpsdr-programmers/Programmer/receivethread.cpp In file included from hpsdr-programmers/Programmer/receivethread.cpp:37:0: ghpsdr3/DRadio/mainwindow.h:5:29: fatal error: frequencysender.h: No such file or directory #include "frequencysender.h" ^ compilation terminated. make: *** [receivethread.o] Error 1 73 ... Sid. On 11/08/14 15:02, kb3omm wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > Steve, This is great news. > > Could you email out the changes you made to get each of the programs > to build and run, to aid those like myself who cant program but can > follow instructions. > > I have tried previously to get John's three programs to build on newer > versions of Qt and Linux without success. > > Though, ghpsdr3-alex and cuSDR run fine and use them every day. > > Hermes, Mint 16, Qt4 and 5 > > 73, Kevin > > > On Mon, Aug 11, 2014 at 9:33 AM, AD0ES > wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi, > > Using --hermes instead of --metis does indeed cure the deafness, > thanx! > > So for the record, at this point all 4 programs are working: > ghpsdr > ghpsdr3 > ghpsdr3-Qt > ghpsdr3-alex > > Note that I had to make minor changes to get several of them to > compile under Ubuntu 14.04.1 (trusty). ? Mostly issues > of header file locations being moved since the last distro. > > Steve ? AD0ES > > On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: > > > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES > wrote: > > > >> ? ? ? ? ghpsdr3-alex: ? runs, but is "deaf" <<< this was > the version I did most of my early testing with > > > > Steve, > > please start the hpsdr-server with --hermes instead of --metis and > > report if this cure the issue. > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 09:38:40 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 10:38:40 -0600 Subject: [hpsdr] PowerSDR & OZY/Mercury/Penelope updating In-Reply-To: <002c01cfb455$2c0e2ca0$842a85e0$@co.za> References: <002c01cfb455$2c0e2ca0$842a85e0$@co.za> Message-ID: <6282414A-39D6-4B4A-B895-F74A508BACD3@valornet.com> Hi Conrad, I haven?t seen any response on the list for your inquiry so I?ll respond. I wonder if you are using the current USBBinaries-Blaster folder? It can be found at http://svn.tapr.org/repos_sdr_hpsdr/trunk/USBBlaster-Binaries/ If not, please get the latest folder and give those files a try. Even if you do already have the latest USBBlaster-Binaries folder the message below seems to indicate that the files may be corrupted somehow. Therefore, in this case too, I?d download a fresh copy of the USBBlaster-Binaries folder and try them to see if that will work for you. I just checked the current USBBlaster-Binaries/Program-Mercury-EPCS16.bat file in the USBBlaster-Binaries folder to verify that it has options for the current Altera Quartus II v13.0 version and Mercury_v3.4; it does, so it should work I would think. 73, Joe K5SO On Aug 9, 2014, at 10:40 PM, Conrad Walker wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hello all > > I decided to update my Ozy/Mercury/Penelope HPSDR on WinXP to v2.7/v3.4/v1.8 with PowerSDR v3.2.17.0. > > Try as I might, I could not flash Mercury with v3.4 firmware via Ozy with USB-Blaster & either Quartus 9.1, 10.1, 12.1 or 13.0. Quartus 9.10 &10.1 gave an error "file Mercury-v3.4.jic corrupted" - unknown argument "Mercury-3.4.cdf", refer to help for legal arguments. Quartus 12.1 and 13.0 gave a "device not ready" error. I was able to flash Mercury v3.3 with Quartus 9.1 & 10.1, and all Quartus versions successfully flashed Penelope v1.8. > > I was able to run PowerSDR v3.2.17.0 with Mercury v3.3 and Penny v1.7 but found that the CW setup option to use Ozy/Hermes for CW keying no longer exists, and so can no longer run CW with my present setup, My earlier PowerSDR installation worked fine. > > Any ideas on sorting this out would be most appreciated. > > 73, > > Conrad Walker ZS6BQQ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wully at bluewin.ch Mon Aug 11 09:44:50 2014 From: wully at bluewin.ch (wully) Date: Mon, 11 Aug 2014 18:44:50 +0200 Subject: [hpsdr] CC-Byte0 from fpga to pc In-Reply-To: <53E8E935.4090808@bluewin.ch> References: <53E8E935.4090808@bluewin.ch> Message-ID: <53E8F302.2070501@bluewin.ch> Hi I have checked the software and found an error in my code: the ccbyte0 brings the IN0,IN1,IN2-States from all boards, that support these. 73, hb9epu On 11.08.2014 18:03, wully wrote: > Hi > > In the Comand-and-Control-Byte 0 from FPGA to PC there are 3 Bits PTT, > Dash and Dot. > > I would like to use at least one of these bits to control an activity. > But I don't know, how these bits are fed. > From the schematics of METIS and fpga-code I think that Pins 6,7 and 8 > on the DB9 connector should be mapped to these (debounced) Bits, > but grounding these does not show an effect on the CC-Byte 0. > > Hardware: > Metis (fpga V2.1) > Penelope (fpga 1.7) > Mercury (fpga 3.3) > > 1) Which hardware- bits control the Bits 0..2 of CCbyte0 when using > the above hardware? > 2) Which hardware- bits control if I use Magister instead of Metis > (IN0, IN1 and IN2 are also present there). > > Thank you for your information. > > 73, hb9epu > > > > 1407775490.0 From douglas.adams at me.com Mon Aug 11 10:00:50 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 13:00:50 -0400 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> Message-ID: Joe, Thank you for your comments. Does the firmware file contain the byte representing the Device ID or is it somehow derived by the firmware from the hardware of the board? I would like to be able to prevent (or maybe just warn) a user from selecting an inappropriate firmware file for their Radio. With the current Board ID I can identify the "sub-type" of the Radio (i.e. Metis, Hermes, Angelia, etc). If the firmware file contains the Device ID (maybe someone can tell me how to find that byte in the firmware file), I could compare that to the Device ID of the Radio. Matching those would get me part way to my intent. I'm in the process of adding Firmware Programming into my own SDR app (on a Mac). If you can picture it, I have two lists on screen; a list of the Radios my app can see on the networks attached to the Mac and a list of the Firmware files it can find at various places on the Mac. I expect the user to select a Radio from the first list and a Firmware file from the second list at which point the Erase & Program button is enabled. The question I've been unable to answer is; how to know that I am about to program my Radio with a Firmware version that is somehow inappropriate? There is another layer to Radio (not Board) identification. As you point out, any one firmware file might be used in multiple Radios. Unfortunately, two Radios with the same Board ID might require different firmware. You also mentioned that the firmware version is reported in the protocol. I agree however I believe some versions are being distinguished by placing a letter after the version (e.g. Hermes v2.9b) and I don't believe the suffix is retained or reported back. As far as naming the firmware files goes, each of us can do that ourselves after downloading them but it would be nice if there was an agreed upon naming scheme being used by the creators of the files. It might avoid some errors. Partly my motivation is simply "getting it right" but partly it's because I also see entries in this list where someone has gotten the wrong firmware installed. On Aug 11, 2014, at 10:12 AM, Joe Martin K5SO wrote: > Hi Doug, > > Interesting proposal that deserves some thought. I don?t disagree that our present system is not a perfect arrangement. > > Keep in mind however that the Board ID is not the only ID parameter ID that is passed in the packets, the actual firmware version is also passed in the packets in a different byte > ....... > > While I certainly appreciate that we might want to specify which specific board type is in use (which we do already in a general sense with the current coarse board ID value) the firmware is used in many cases in a variety of hardware configurations > ....... > > 73, Joe K5SO > 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 10:15:38 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 11:15:38 -0600 Subject: [hpsdr] CC-Byte0 from fpga to pc In-Reply-To: <53E8F302.2070501@bluewin.ch> References: <53E8E935.4090808@bluewin.ch> <53E8F302.2070501@bluewin.ch> Message-ID: Okay, very good. I just checked the behavior of bit 2 in the C0 command bytes coming from Metis, using current firmware in all boards, and it responds fine to the DB9 input pin grounding for DASH. I don?t know why you?d want to use old firmware/software but maybe you have a reason to do so. I did not take time to load old version of firmware for these tests. Current firmware is: Metis_v2.9 Mercury_v3.4 Penelope_v1.8 Current software for PSDR is: PowerSDR_mRX_PS_v3.1.17.0 Thanks for updating your situation! 73, Joe K5SO On Aug 11, 2014, at 10:44 AM, wully wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > I have checked the software and found an error in my code: the ccbyte0 brings the IN0,IN1,IN2-States from all boards, that support these. > > 73, hb9epu > > > On 11.08.2014 18:03, wully wrote: >> Hi >> >> In the Comand-and-Control-Byte 0 from FPGA to PC there are 3 Bits PTT, Dash and Dot. >> >> I would like to use at least one of these bits to control an activity. But I don't know, how these bits are fed. >> From the schematics of METIS and fpga-code I think that Pins 6,7 and 8 on the DB9 connector should be mapped to these (debounced) Bits, >> but grounding these does not show an effect on the CC-Byte 0. >> >> Hardware: >> Metis (fpga V2.1) >> Penelope (fpga 1.7) >> Mercury (fpga 3.3) >> >> 1) Which hardware- bits control the Bits 0..2 of CCbyte0 when using the above hardware? >> 2) Which hardware- bits control if I use Magister instead of Metis (IN0, IN1 and IN2 are also present there). >> >> Thank you for your information. >> >> 73, hb9epu >> 1407777338.0 From kb3omm at gmail.com Mon Aug 11 10:41:31 2014 From: kb3omm at gmail.com (kb3omm) Date: Mon, 11 Aug 2014 13:41:31 -0400 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <53E8EA3D.9060807@blueyonder.co.uk> References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> <53E8EA3D.9060807@blueyonder.co.uk> Message-ID: Steve, Sid, Thanks for your notes. I will try these and report back 73, Kevin On Mon, Aug 11, 2014 at 12:07 PM, Sid Boyce wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > I modified GHPSDR3-Qt/FULL/KV0S/KV0S.pro, adding the Qt include PATHS > INCLUDEPATH += . \ > /usr/include/QtMultimedia /usr/include/QtNetwork > /usr/include/QtXml \ > ghpsdr3/DRadio \ > griffin/griffinID \ > > Missing file frequencysender.h:- > IQt-Radio-Programs/QtHPSDRServer/client -I. -I. -o receivethread.o > hpsdr-programmers/Programmer/receivethread.cpp > In file included from hpsdr-programmers/Programmer/receivethread.cpp:37:0: > ghpsdr3/DRadio/mainwindow.h:5:29: fatal error: frequencysender.h: No such > file or directory > #include "frequencysender.h" > ^ > compilation terminated. > make: *** [receivethread.o] Error 1 > 73 ... Sid. > > On 11/08/14 15:02, kb3omm wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > > > > Steve, This is great news. > > Could you email out the changes you made to get each of the programs to > build and run, to aid those like myself who cant program but can follow > instructions. > > I have tried previously to get John's three programs to build on newer > versions of Qt and Linux without success. > > Though, ghpsdr3-alex and cuSDR run fine and use them every day. > > Hermes, Mint 16, Qt4 and 5 > > 73, Kevin > > > On Mon, Aug 11, 2014 at 9:33 AM, AD0ES wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi, >> >> Using --hermes instead of --metis does indeed cure the deafness, thanx! >> >> So for the record, at this point all 4 programs are working: >> ghpsdr >> ghpsdr3 >> ghpsdr3-Qt >> ghpsdr3-alex >> >> Note that I had to make minor changes to get several of them to compile >> under Ubuntu 14.04.1 (trusty). ? Mostly issues >> of header file locations being moved since the last distro. >> >> Steve ? AD0ES >> >> On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: >> >> > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES wrote: >> > >> >> ? ? ? ? ghpsdr3-alex: ? runs, but is "deaf" <<< this was the >> version I did most of my early testing with >> > >> > Steve, >> > please start the hpsdr-server with --hermes instead of --metis and >> > report if this cure the issue. >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > -- > 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 > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 11:15:47 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 12:15:47 -0600 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> Message-ID: Doug, RR, understood; but I don?t entirely agree with your assessment of the present situation. Let me respond to each of the issues to which I refer: 1) Answering your question: Yes, the firmware Verilog design contains the DEVICE ID number in the Verilog code itself; it?s coded into the ethernet packets directly. For example, the hardware ID value for Angelia is hardcoded in the Angelia Verilog design into line1059 of the TX_MAC module in the Verilog design. It?s done similarly, if not identically, in the Verilog firmware designs for all the other HPSDR and ANAN-series boards. 2) I see what it is that you are trying to accomplish and it?s an admirable goal I think. It seems to me (with one exception which I will mention next) that the current hardware ID scheme works just fine for identifying the hardware to match with firmware. I am not aware of any firmware named for a hardware board that does not work in that board, regardless of the configuration of the board (the exception I mentioned notwithstanding). Namely, the hardware ID specifies whether the board is a Metis, Hermes, Griffin, Angelia, or Orion. The user should be aware, for example, which board his radio uses and therefore be able to match the board with the necessary firmware since the firmware filename includes the board name with which it is intended to be used. 3) The exception I mention above has to do with the minor difference in Apache Labs versions of firmware that are labeled ?b? suffix, in which the switch point for 10m filters is different from radios using Alex filters. The operational effect of not using a ?b? version in an ANAN radio that has the PA filters is perhaps a bit lower maximum output power on 10m; that?s it. Otherwise the firmware will work just fine. 4) I agree with you that labeling firmware versions with a ?b? suffix is not a good idea at all because the firmware version reporting protocol within firmware does not allow for letters in the firmware version numbers. In my opinion, an entirely new firmware version number (using numbers exclusively, no sub-letters) should be used, even for that small distinction of the 10m filter switch point. I always avoid using letter suffix nomenclature in released firmware versions, because there is no way to distinguish those ?modified? versions from the original versions by looking at the version numbers being reported by the firmware. I much prefer to use an entirely different firmware version number which is acceptable in the current firmware version number protocol (no letters) and easily distinguishable from anything else by simply looking at the firmware version number that is reported by the firmware. With regard to loading the wrong firmware, if someone loads Metis code into Angelia, as one example, there really is no excuse for doing it as the Metis firmware has the ?Metis? name in the firmware filename. It?s always a recoverable event in any case, even if it happens. Granted you must use a blaster cable to recover but that?s the penalty you SHOULD have to pay for not reading the name, in my view. Next time you will read it. Further, quite simply, if you own an ANAN radio and don?t even know what major board type the radio has in it (Hermes, Angelia, or Orion) you likely are not well suited to be a user of that radio, as you?re going to have tremendous difficulties operating the thing and updating its firmware later on; my personal opion, of course. I understand your desire to make your code bulletproof against ignorance, and I applaud the attempt, but I think we can go overboard in that area. There are some people who are simply not well suited to using SDR, as I have come to appreciate. I used to think otherwise but sadly now I don?t. These are complex, high-performance radios and they need marginally compentent users at least in order to be able to realize the advantages that they can offer. Again, my opion. You?re all welcome to have a different opinion, if you wish. 73, Joe K5SO 1407780947.0 From douglas.adams at me.com Mon Aug 11 11:31:54 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 14:31:54 -0400 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> Message-ID: <5C402B1B-058D-4861-A53C-B46863D74269@me.com> Joe (et all), Well stated, let me summarize my take away. 1. If I match the name in the firmware file name (e.g. "Hermes", "Metis", "Angelia") with the Board ID from my Radio (translated to the appropriate string) I will never load a non-operative firmware (it may have minor issues such as the filter control but it will work). 2. We should suggest to those who create firmware files that they only use numbered versions (i.e. no suffixes). I can live with #1, I'll implement it in my code as a Warning (to keep me from doing something dumb, I don't own a Blaster, yet). I'm not sure how we get people to comply with #2. On Aug 11, 2014, at 2:15 PM, Joe Martin K5SO wrote: > Doug, > > RR, understood; but I don?t entirely agree with your assessment of the present situation. Let me respond to each of the issues to which I refer: > > .... > These are complex, high-performance radios and they need marginally compentent users at least in order to be able to realize the advantages that they can offer. Again, my opion. You?re all welcome to have a different opinion, if you wish. > > 73, Joe K5SO > > 73?s Doug - K3TZR 1407781914.0 From k5so at valornet.com Mon Aug 11 11:46:59 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 12:46:59 -0600 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <5C402B1B-058D-4861-A53C-B46863D74269@me.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> <5C402B1B-058D-4861-A53C-B46863D74269@me.com> Message-ID: <87FDB69E-648D-4E93-953D-89C99190F44A@valornet.com> Doug, Yes. I think #2 will take care of itself given the amount of angst it has caused already, hihi. We learn as we go. 73, Joe K5SO On Aug 11, 2014, at 12:31 PM, Doug Adams wrote: > Joe (et all), > > Well stated, let me summarize my take away. > > 1. If I match the name in the firmware file name (e.g. "Hermes", "Metis", "Angelia") with the Board ID from my Radio (translated to the appropriate string) I will never load a non-operative firmware (it may have minor issues such as the filter control but it will work). > > 2. We should suggest to those who create firmware files that they only use numbered versions (i.e. no suffixes). > > I can live with #1, I'll implement it in my code as a Warning (to keep me from doing something dumb, I don't own a Blaster, yet). I'm not sure how we get people to comply with #2. > > > On Aug 11, 2014, at 2:15 PM, Joe Martin K5SO wrote: > >> Doug, >> >> RR, understood; but I don?t entirely agree with your assessment of the present situation. Let me respond to each of the issues to which I refer: >> >> .... > >> These are complex, high-performance radios and they need marginally compentent users at least in order to be able to realize the advantages that they can offer. Again, my opion. You?re all welcome to have a different opinion, if you wish. >> >> 73, Joe K5SO >> >> > > 73?s > Doug - K3TZR > > > > > > 1407782819.0 From douglas.adams at me.com Mon Aug 11 11:48:50 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 14:48:50 -0400 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> Message-ID: <1B7A282F-FFC2-4C41-B1BC-B5347FF2DD1A@me.com> Thanks Dave, Although I haven't done any C++ in years I looked through the code and got the idea. I see that you are doing what I've decided to do (see my last post), making sure the firmware file name jives with the Board ID. I also found the definitions for the Max Timeouts for each board which I'll incorporate into my programmer. Hopefully I won't brick my radio in the process of debugging my code. On Aug 11, 2014, at 2:22 PM, Dave Larsen wrote: > Doug -- > > in the HPSDRProgrammer the code you are looking for is in http://svn.tapr.org/repos_sdr_hpsdr/trunk/KV0S/hpsdr-programmers/HPSDRProgrammerV2-nopcap/mainwindow.cpp in the browse function. > > The current HPSDRProgrammer talks to the old firmware to load the flash memory. You are right that the a and b are not kept. Joe and Phil produce most of the firmware for these boards and the naming is up to them. Internally the store the board type and the firmware version is all that is stored and read. > > Part of the issue is some of this changes the bootloader firm, which is install at manufacture not not changed. This is the recover system. we have no causal system for users to replace the bootloader. > > Hope this helps > > Dave KV0S > 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vbv at blueyonder.co.uk Mon Aug 11 13:54:18 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 11 Aug 2014 21:54:18 +0100 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> <53E8EA3D.9060807@blueyonder.co.uk> Message-ID: <53E92D7A.3090004@blueyonder.co.uk> Hi Steve and Kevin, This time instead of the KV0S svn I used "svn co http://svn.tapr.org/repos_sdr_hpsdr/trunk/N6LYT/Qt" which built without changes slipstream:/usr/src/Qt/trunk # ls -l bin total 2484 -rwxr-xr-x 1 root root 1481425 Aug 11 20:33 QtDSPServer -rwxr-xr-x 1 root root??? 396047 Aug 11 20:32 QtHPSDRServer -rwxr-xr-x 1 root root??? 663150 Aug 11 20:34 QtRadio Building on openSUSE which uses lib64 instead of lib. libusb-1.0 is in /usr/include. Makefile changes ========== ghpsdr ---------- INCLUDES=-I. -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/gdk-pixbuf-2.0\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/atk-1.0 -I/usr/include/cairo\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/pango-1.0 -I/usr/include/glib-2.0\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/freetype2 -I/usr/include/libpng12 \ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/libusb-1.0 Exploded and built DttSP.tar.gz in the ghpsdr directory LIBS=-L. -L/usr/src/openHPSDR/ghpsdr/DttSP -lDttSP -lpthread -lusb-1.0\ ??? ??? ??? ??? -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0\ ??? ??? ??? ??? -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lz\ ??? ??? ??? ??? -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lfftw3f slipstream:/usr/src/openHPSDR/ghpsdr # ls -l bin total 1336 -rwxr-xr-x 1 root root 1126746 Aug 11 20:47 ghpsdr -rwxr-xr-x 1 root root??? ??? ??? ??? 256 Aug 11 20:40 ghpsdr.sh -rw-r--r-- 1 root root??? ??? 21032 Aug 11 20:40 icon.png -rwxr-xr-x 1 root root??? ??? ??? 1343 Aug 11 20:40 initozy drwxr-xr-x 2 root root??? ??? ??? 4096 Aug 11 20:40 linux64 -rwxr-xr-x 1 root root??? ??? 14555 Aug 11 20:40 loadFPGA -rwxr-xr-x 1 root root??? ??? 14324 Aug 11 20:40 loadFW drwxr-xr-x 2 root root??? ??? ??? 4096 Aug 11 20:40 mac -rw-r--r-- 1 root root??? ??? 21862 Aug 11 20:40 ozyfw-sdr1k.hex -rw-r--r-- 1 root root??? 121875 Aug 11 20:40 Ozy_Janus.rbf -rwxr-xr-x 1 root root??? ??? 14687 Aug 11 20:40 write_i2c ghpsdr3-alex always has been OK. 73 ... Sid. -- 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 1407790458.0 From andrea.montefusco at gmail.com Mon Aug 11 14:04:08 2014 From: andrea.montefusco at gmail.com (andrea montefusco) Date: Mon, 11 Aug 2014 23:04:08 +0200 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <1407708969.5462.23.camel@Barossa> References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> <1407708969.5462.23.camel@Barossa> Message-ID: On Aug 11, 2014 12:16 AM, "Berndt Josef Wulf" wrote: > > G'day, > > A modified version of cuSDR can be downloaded from > >http://www.ping.net.au/20140126_cuSDR64src.tar.gz > > It requires QT5 and may not work with the current firmware change, so > your mileage may wary. Hi Berndt, That is a good news, especially for people trying to use cuSDR on Jetson board: together with Ken N9VV we compiled the original cuSDR but we didn't manage to achieve a proper working with the Qt 4.x. In any case, I just compiled your code with qt 5.3 on Ubuntu 12.04 (i5) and it works well (Metis 2.8, Mercury 3.4). *am* -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vbv at blueyonder.co.uk Mon Aug 11 17:29:04 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Tue, 12 Aug 2014 01:29:04 +0100 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> <53E8EA3D.9060807@blueyonder.co.uk> Message-ID: <53E95FD0.4000106@blueyonder.co.uk> Hi Steve and Kevin, Instead of the KV0S svn I use "svn co http://svn.tapr.org/repos_sdr_hpsdr/trunk/N6LYT/Qt" built without changes /usr/src/Qt/trunk # ls -l bin total 2484 -rwxr-xr-x 1 root root 1481425 Aug 11 20:33 QtDSPServer -rwxr-xr-x 1 root root?????? 396047 Aug 11 20:32 QtHPSDRServer -rwxr-xr-x 1 root root?????? 663150 Aug 11 20:34 QtRadio Building on openSUSE which uses lib64. libusb-1.0 is in /usr/include. Makefile changes ========== ghpsdr ---------- INCLUDES=-I. -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include\ -I/usr/include/gdk-pixbuf-2.0\ -I/usr/include/atk-1.0 -I/usr/include/cairo\ -I/usr/include/pango-1.0 -I/usr/include/glib-2.0\ -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1\ -I/usr/include/freetype2 -I/usr/include/libpng12 \ -I/usr/include/libusb-1.0 Built DttSP.tar.gz in ghpsdr directory LIBS=-L. -L/usr/src/openHPSDR/ghpsdr/DttSP -lDttSP -lpthread -lusb-1.0\ -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0\ -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lz\ -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lfftw3f slipstream:/usr/src/openHPSDR/ghpsdr # ls -l bin/ghpsdr -rwxr-xr-x 1 root root 1126746 Aug 11 20:47 ghpsdr ghpsdr3-alex always has been OK. 73 ... Sid. -- 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 1407803344.0 From g3vbv at blueyonder.co.uk Mon Aug 11 17:39:58 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Tue, 12 Aug 2014 01:39:58 +0100 Subject: [hpsdr] 20140126_cuSDR64src In-Reply-To: References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> <1407708969.5462.23.camel@Barossa> Message-ID: <53E9625E.5070203@blueyonder.co.uk> No problems on openSUSE x86_64, built with Qt-5.3.1. 73 ... Sid. On 11/08/14 22:04, andrea montefusco wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > > On Aug 11, 2014 12:16 AM, "Berndt Josef Wulf" > wrote: > > > > G'day, > > > > A modified version of cuSDR can be downloaded from > > > >http://www.ping.net.au/20140126_cuSDR64src.tar.gz > > > > It requires QT5 and may not work with the current firmware change, so > > your mileage may wary. > > -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vbv at blueyonder.co.uk Tue Aug 12 12:46:15 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Tue, 12 Aug 2014 20:46:15 +0100 Subject: [hpsdr] 20140126_cuSDR64src In-Reply-To: <53E9625E.5070203@blueyonder.co.uk> References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> <1407708969.5462.23.camel@Barossa> <53E9625E.5070203@blueyonder.co.uk> Message-ID: <53EA6F07.8060000@blueyonder.co.uk> Hi Andrea, Just for fun I built it on the ODROID-U3 but have not got around to testing it. root at odroidu3:/a1/ANDREA/cuSDR64# file bin/cuSDR64 bin/cuSDR64: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=ad66531161d9dd1be3a83e4720c1436343b867ef, not stripped root at odroidu3:/a1/ANDREA/cuSDR64# cuSDR32 modified and built with qt-5.3.1 should also be no problem. 73 ... Sid. On 12/08/14 01:39, Sid Boyce wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > No problems on openSUSE x86_64, built with Qt-5.3.1. > 73 ... Sid. > > On 11/08/14 22:04, andrea montefusco wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> >> >> >> On Aug 11, 2014 12:16 AM, "Berndt Josef Wulf" > > wrote: >> > >> > G'day, >> > >> > A modified version of cuSDR can be downloaded from >> > >> >http://www.ping.net.au/20140126_cuSDR64src.tar.gz >> > >> > It requires QT5 and may not work with the current firmware change, so >> > your mileage may wary. >> >> > > -- > 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 > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gokoyev+k3it at gmail.com Thu Aug 14 07:14:26 2014 From: gokoyev+k3it at gmail.com (k3it) Date: Thu, 14 Aug 2014 10:14:26 -0400 Subject: [hpsdr] Updates to the Skimmer server interface DLL v14.8.13 Message-ID: An updated version of HermesIntf.dll Skimmer server interface for HPSDR is available at *https://sourceforge.net/projects/hermesintf/files/ * new h/w support: - Afedri SDR-net in HPSDR emulation mode (firmware 228e and higher) - N1GP RTL_hpsdr (see https://github.com/n1gp/rtl_hpsdr ) - up to seven receivers in Hermes depending on the firmware revision. Support of the latest v2.9 firmware (4 rcvrs) - additonal HPSDR variants (Angelia, Metis, etc) increased logging level in HermesIntf_log_file.txt Supported sample rates/receivers: 48/96/192 Khz Hermes: - Firmware version *1.8* (download from the dxatlas.com web site) - 7 receivers - Firmware version 2.4,2.5 - 5 receivers - Firmware version 2.9 - 4 receivers - Other fw revisions: defaults to 4 receivers Angelia: - 7 receivers Metis: - 4 receivers N1GP RTL dongle in HPSDR emulation mode: - up to 8 receivers, depending on the number of connected dongles Afedri SDR-NET single and dual channel in HPSDR emulation mode: - 1 or 2 receivers Please email if you run into any problems 73! Vasiliy K3IT -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrospopo at sbcglobal.net Mon Aug 11 09:38:50 2014 From: jrospopo at sbcglobal.net (Jim Rospopo) Date: Mon, 11 Aug 2014 11:38:50 -0500 Subject: [hpsdr] Newbie Question on computer and Munin Message-ID: <023201cfb582$bb967750$32c365f0$@sbcglobal.net> Newbie question, I just got the rest of the cards for my HPSDR. I was wondering what are the minimum requirements for the computer. I'll most likely be using the PowerSDR software or I may use it on my iMac with those programs. Are these programs optimized for the intel processors or will the AMD processors work equally well ? Also any minimum RAM requirements and or processor speeds ? Also, is there any more information on the Munin PA ? I know there was a group buy a while back. Are any kits still available from that buy. I also heard that TAPR was thinking of offering it as a kit. Is there any more information on that front. I'm sure as I proceed I'll have more questions. Excited to get this put together and operating. 73's Jim KE4CON -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa8k73 at gmail.com Fri Aug 15 19:23:24 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 15 Aug 2014 22:23:24 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/16 Message-ID: <53EEC09C.2040106@gmail.com> The 16/Aug TeamSpeak mp3 (61 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3511 > or < http://www.hamsdr.com/dnld.aspx > Only silence truncation editing was done on this recording. 1408155804.0 From phil at pharman.org Sun Aug 17 01:36:07 2014 From: phil at pharman.org (Phil Harman) Date: Sun, 17 Aug 2014 16:36:07 +0800 Subject: [hpsdr] Hermes manual update Message-ID: <33210BB5CEBB48C2BA7FC92CBE75EE0F@ShackPC2> All, There is an update to the Hermes User Manual (V1.18) available from: http://openhpsdr.org/documents.php This contains additional information on the use of J17 when an external supply is used. Thanks to Rob, VE3EW, for the updated information. 73 Phil...VK6PH --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at vspl.co.uk Sun Aug 17 09:37:01 2014 From: chris at vspl.co.uk (Chris Smith) Date: Sun, 17 Aug 2014 17:37:01 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 Message-ID: <20140817163704.A6AAD48278@diego.dreamhost.com> Hi Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. Eventually cuSDR64 built and I could run it on the TK1 It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? Exciting to be able to use my TK1 in anger. Cheers & 73 Chris G4NUX 1408293421.0 From wulf at ping.net.au Sun Aug 17 14:02:25 2014 From: wulf at ping.net.au (Berndt Josef Wulf) Date: Mon, 18 Aug 2014 06:32:25 +0930 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <20140817163704.A6AAD48278@diego.dreamhost.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <1408309345.3501.6.camel@Barossa> G'day Chris, The -j4 option defines the number of threads being used for the build process in this case 4. I use -j n where n is number of CPU cores available on the system +1. It significantly speeds up the building process on multi-core systems. cuSDR's CPU load is generally high including Intel based *nix systems. I never looked into this, as I still hoping for an updated version from Hermann. The chief reasons for me using cuSDR is that it runs under Linux/NetBSD and the many features that made using it a pleasure. 73, Berndt VK5ABN On Sun, 2014-08-17 at 17:37 +0100, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my > recently acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for > some years now, building the libraries from sources under Fedora Linux > & OSX. I found the published build instructions using git a bit > longwinded but eventually succeeded. Does anyone know what the -j4 > option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after > changing the symlink in /usr/bin so that qmake pointed to the Qt-5 > version in /usr/local/Qt-5/bin I could run qmake at the top level of > cuSDR to bring the Makefile up to date. I didn't do a make clean so > some .o files reported "wrong file type" but removing the 3 offending > .o files led me to the next problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 > https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz > ) and apart from configure requiring a couple of qualifiers ( > ./configure --enable-single --enable-shared ) that library built and > installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run > cuSDR on any platform before) but everything appeared to be working. My > Atlas hardware was correctly reported along with ancient f/w versions > and I could hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a > roller wheel in the shack so the only way I seem to be able to tune is > to drag the frequency bar under the display left-right. That is far too > crude to tune an individual QSO but got me some audio recognisable as a > contact. > > One thing which alarms me slightly is that the CPU usage reported is in > the range 152-175% I assume that is reporting that more than one core > (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web > page: http://openhpsdr.org Archives: > http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408309345.0 From g3vbv at blueyonder.co.uk Sun Aug 17 15:12:17 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Sun, 17 Aug 2014 23:12:17 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <20140817163704.A6AAD48278@diego.dreamhost.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <53F128C1.7040900@blueyonder.co.uk> Hi Chris, As mentioned - The first impression is that the TK1 is 64-bit, but it is quad-core 32-bit. It's still a powerful beast, CUDA ensures that. The next version apparently due later this year is dual-core 64-bit. 20140126_cuSDR64src.tar.gz comes with .o files in bld/o which are compiled x86_64 files, "make clean" will get rid of them, then do "make -j 4". Be aware that different distros, Fedora, openSUSE, Ubuntu etc. use different package names so you must refine your search terms. Typically all distros provide most stuff so no need to build core applications, libraries or utilities. Unless you need a library at a higher level than the distro provides, avoid building and installing what is already provided. You can create deep pits to fall into later, sometimes much later if you are not careful. Ubuntu -- apt-cache search fftw. Fedora -- yum search fftw. openSUSE -- zypper se fftw Don't be tempted to enter package names as they may appear in another distro. When in doubt shorten the search string, e.g There are no packages with fftw3 in the name in Fedora while there are many in openSUSE and Ubuntu but again the package names differ. # yum search fftw3 Loaded plugins: langpacks, refresh-packagekit Warning: No matches found for: fftw3 No matches found These are the fft libraries installed in Fedora 20. # rpm -qa|grep fft fftw-libs-quad-3.3.4-3.fc20.x86_64 fftw-libs-single-3.3.4-3.fc20.x86_64 fftw-3.3.4-3.fc20.x86_64 fftw-libs-3.3.4-3.fc20.x86_64 fftw-libs-double-3.3.4-3.fc20.x86_64 fftw-devel-3.3.4-3.fc20.x86_64 fftw-libs-long-3.3.4-3.fc20.x86_64 Building Qt5, recommend using the instructions for ghpsdr3-alex which work on any platform. The instructions on the wiki for building ghpsdr3-alex avoid the use of symlinks, e.g if qt5 is built in /home/fred - "export PATH=/home/fred/qt5/qtbase/bin:$PATH" sets it up to use qt5. # qmake -v QMake version 3.0 Using Qt version 5.3.1 in /home/fred/qt5/qtbase/lib 73 ... Sid. On 17/08/14 17:37, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. > > One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- 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 1408313537.0 From chris at vspl.co.uk Sun Aug 17 20:47:21 2014 From: chris at vspl.co.uk (Chris Smith) Date: Mon, 18 Aug 2014 04:47:21 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <53F128C1.7040900@blueyonder.co.uk> References: <20140817163704.A6AAD48278@diego.dreamhost.com> <53F128C1.7040900@blueyonder.co.uk> Message-ID: <20140818035052.63DBD48319@diego.dreamhost.com> Hi Sid As I mentioned off list I'm not a fan of Debian based distros because I find apt so difficult to use compared to yum. But by widening my search pattern in apt-cache search I was able to find libfftw3, so I've removed the version I built from sources and installed the package. cuSDR builds OK so I'm happy with that. Regarding Qt5, I would normally add to PATH but wanted a quick and dirty fix so changing the symlink was favourite. :-) 73, Chris G4NUX Sent from my iPad > On 17 Aug 2014, at 23:12, Sid Boyce wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Chris, > As mentioned - The first impression is that the TK1 is 64-bit, but it is quad-core 32-bit. It's still a powerful beast, CUDA ensures that. > > The next version apparently due later this year is dual-core 64-bit. > > 20140126_cuSDR64src.tar.gz comes with .o files in bld/o which are compiled x86_64 files, "make clean" will get rid of them, then do "make -j 4". > > Be aware that different distros, Fedora, openSUSE, Ubuntu etc. use different package names so you must refine your search terms. > Typically all distros provide most stuff so no need to build core applications, libraries or utilities. > Unless you need a library at a higher level than the distro provides, avoid building and installing what is already provided. You can create deep pits to fall into later, sometimes much later if you are not careful. > > Ubuntu -- apt-cache search fftw. > Fedora -- yum search fftw. > openSUSE -- zypper se fftw > > Don't be tempted to enter package names as they may appear in another distro. When in doubt shorten the search string, e.g There are no packages with fftw3 in the name in Fedora while there are many in openSUSE and Ubuntu but again the package names differ. > # yum search fftw3 > Loaded plugins: langpacks, refresh-packagekit > Warning: No matches found for: fftw3 > No matches found > > These are the fft libraries installed in Fedora 20. > # rpm -qa|grep fft > fftw-libs-quad-3.3.4-3.fc20.x86_64 > fftw-libs-single-3.3.4-3.fc20.x86_64 > fftw-3.3.4-3.fc20.x86_64 > fftw-libs-3.3.4-3.fc20.x86_64 > fftw-libs-double-3.3.4-3.fc20.x86_64 > fftw-devel-3.3.4-3.fc20.x86_64 > fftw-libs-long-3.3.4-3.fc20.x86_64 > > Building Qt5, recommend using the instructions for ghpsdr3-alex which work on any platform. > The instructions on the wiki for building ghpsdr3-alex avoid the use of symlinks, e.g if qt5 is built in /home/fred - "export PATH=/home/fred/qt5/qtbase/bin:$PATH" sets it up to use qt5. > # qmake -v > QMake version 3.0 > Using Qt version 5.3.1 in /home/fred/qt5/qtbase/lib > 73 ... Sid. > >> On 17/08/14 17:37, Chris Smith wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi >> >> Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. >> >> Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? >> >> Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. >> >> I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. >> >> Eventually cuSDR64 built and I could run it on the TK1 >> >> It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. >> >> The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. >> >> One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? >> >> Exciting to be able to use my TK1 in anger. >> >> Cheers & 73 >> >> Chris G4NUX >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > -- > 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 > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408333641.0 From g3vbv at blueyonder.co.uk Mon Aug 18 03:30:39 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 18 Aug 2014 11:30:39 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <53f1781b.ef21700a.2a89.ffff8ac3SMTPIN_ADDED_MISSING@mx.google.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> <53F128C1.7040900@blueyonder.co.uk> <53f1781b.ef21700a.2a89.ffff8ac3SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <53F1D5CF.4010805@blueyonder.co.uk> Hi Chris, I use whatever is before me, I have had to do that for decades working with 12 or more different OS's - yum search, zypper search/se, apt-*, aptitude search, pacman -S, not much of a difference between them really. I also stash tons of executable scripts that lighten the key pounding load. I have them in /usr/local/mybin which is permanently added to PATH. lancelot at slipstream:~> cat /usr/local/mybin/BUILD_GNURADIO #!/bin/sh cmake -DPYTHON_EXECUTABLE=/usr/bin/python2.7 -DPYTHON_INCLUDE_DIR=/usr/include/python2.7 -DPYTHON_LIBRARY=/usr/lib64/libpython2.7.so -DCMAKE_INSTALL_PREFIX=/usr . lancelot at slipstream:~> cat /usr/local/mybin/QUARTUS #!/bin/sh cd /home/lancelot/altera/13.0/quartus/bin/ ./quartus& lancelot at slipstream:~> cat /usr/local/mybin/HERMES_384K #!/bin/sh hpsdr-server --hermes 255 --samplerate 384000 --interface enp3s0 & There is only one OS I have ever shied away from as I was never required to use it to earn a daily crust. The one with the fur coat and no under garments. 73 ... Sid. On 18/08/14 04:47, Chris Smith wrote: > Hi Sid > > As I mentioned off list I'm not a fan of Debian based distros because I find apt so difficult to use compared to yum. But by widening my search pattern in apt-cache search I was able to find libfftw3, so I've removed the version I built from sources and installed the package. cuSDR builds OK so I'm happy with that. > > Regarding Qt5, I would normally add to PATH but wanted a quick and dirty fix so changing the symlink was favourite. :-) > > 73, Chris G4NUX > > Sent from my iPad > >> On 17 Aug 2014, at 23:12, Sid Boyce wrote: >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Chris, >> As mentioned - The first impression is that the TK1 is 64-bit, but it is quad-core 32-bit. It's still a powerful beast, CUDA ensures that. >> >> The next version apparently due later this year is dual-core 64-bit. >> >> 20140126_cuSDR64src.tar.gz comes with .o files in bld/o which are compiled x86_64 files, "make clean" will get rid of them, then do "make -j 4". >> >> Be aware that different distros, Fedora, openSUSE, Ubuntu etc. use different package names so you must refine your search terms. >> Typically all distros provide most stuff so no need to build core applications, libraries or utilities. >> Unless you need a library at a higher level than the distro provides, avoid building and installing what is already provided. You can create deep pits to fall into later, sometimes much later if you are not careful. >> >> Ubuntu -- apt-cache search fftw. >> Fedora -- yum search fftw. >> openSUSE -- zypper se fftw >> >> Don't be tempted to enter package names as they may appear in another distro. When in doubt shorten the search string, e.g There are no packages with fftw3 in the name in Fedora while there are many in openSUSE and Ubuntu but again the package names differ. >> # yum search fftw3 >> Loaded plugins: langpacks, refresh-packagekit >> Warning: No matches found for: fftw3 >> No matches found >> >> These are the fft libraries installed in Fedora 20. >> # rpm -qa|grep fft >> fftw-libs-quad-3.3.4-3.fc20.x86_64 >> fftw-libs-single-3.3.4-3.fc20.x86_64 >> fftw-3.3.4-3.fc20.x86_64 >> fftw-libs-3.3.4-3.fc20.x86_64 >> fftw-libs-double-3.3.4-3.fc20.x86_64 >> fftw-devel-3.3.4-3.fc20.x86_64 >> fftw-libs-long-3.3.4-3.fc20.x86_64 >> >> Building Qt5, recommend using the instructions for ghpsdr3-alex which work on any platform. >> The instructions on the wiki for building ghpsdr3-alex avoid the use of symlinks, e.g if qt5 is built in /home/fred - "export PATH=/home/fred/qt5/qtbase/bin:$PATH" sets it up to use qt5. >> # qmake -v >> QMake version 3.0 >> Using Qt version 5.3.1 in /home/fred/qt5/qtbase/lib >> 73 ... Sid. >> >>> On 17/08/14 17:37, Chris Smith wrote: >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> Hi >>> >>> Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. >>> >>> Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? >>> >>> Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. >>> >>> I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. >>> >>> Eventually cuSDR64 built and I could run it on the TK1 >>> >>> It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. >>> >>> The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. >>> >>> One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? >>> >>> Exciting to be able to use my TK1 in anger. >>> >>> Cheers & 73 >>> >>> Chris G4NUX >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> -- >> 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 >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 1408357839.0 From hvh.net at gmail.com Mon Aug 18 04:24:23 2014 From: hvh.net at gmail.com (Hermann) Date: Mon, 18 Aug 2014 13:24:23 +0200 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <20140817163704.A6AAD48278@diego.dreamhost.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: Dear Chris, congratulations! What I noticed last year when I did some experiments with cuSDR on my Gentoo box is also a higher CPU load compared to a Windows box. I did not took a closer look at yet where this might come from, but it could depend on many things. I will compile cuSDR on my Jetson in short (I hope so, hi) and will take a closer look at. Maybe the strategy of advising/generating threads in cuSDR has to be modified to suit the Linux scheduler, but this is purely speculative for now. 73, Hermann DL3HVH On Sun, Aug 17, 2014 at 6:37 PM, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my recently > acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for some > years now, building the libraries from sources under Fedora Linux & OSX. I > found the published build instructions using git a bit longwinded but > eventually succeeded. Does anyone know what the -j4 option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after > changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version > in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring > the Makefile up to date. I didn't do a make clean so some .o files reported > "wrong file type" but removing the 3 offending .o files led me to the next > problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 > https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz > ) and apart from configure requiring a couple of qualifiers ( ./configure > --enable-single --enable-shared ) that library built and installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run cuSDR > on any platform before) but everything appeared to be working. My Atlas > hardware was correctly reported along with ancient f/w versions and I could > hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a > roller wheel in the shack so the only way I seem to be able to tune is to > drag the frequency bar under the display left-right. That is far too crude > to tune an individual QSO but got me some audio recognisable as a contact. > > One thing which alarms me slightly is that the CPU usage reported is in > the range 152-175% I assume that is reporting that more than one core > (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at vspl.co.uk Mon Aug 18 06:32:16 2014 From: chris at vspl.co.uk (Chris Smith) Date: Mon, 18 Aug 2014 14:32:16 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <20140818133219.75557481E0@diego.dreamhost.com> Hi Herman I'm so encouraged by the success of this venture that I'm going to build cuSDR64 on my HPSDR dual-boot system - WinXP/F19. I'd like to be shot of Windows for good. PowerSDR is the only piece of software that I currently use that needs Windows. I'll let you know how I get on there. 73, Chris G4NUX On 18 Aug 2014, at 12:24, Hermann wrote: > Dear Chris, > > congratulations! What I noticed last year when I did some experiments with cuSDR on my Gentoo box is also a higher CPU load compared to a Windows box. I did not took a closer look at yet where this might come from, but it could depend on many things. I will compile cuSDR on my Jetson in short (I hope so, hi) and will take a closer look at. Maybe the strategy of advising/generating threads in cuSDR has to be modified to suit the Linux scheduler, but this is purely speculative for now. > > > 73, Hermann DL3HVH > > > On Sun, Aug 17, 2014 at 6:37 PM, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. > > One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1408368736.0 From irbsurfing at yahoo.co.uk Tue Aug 19 13:04:06 2014 From: irbsurfing at yahoo.co.uk (Andrew) Date: Tue, 19 Aug 2014 21:04:06 +0100 Subject: [hpsdr] Wideband waterfall display Message-ID: <1408478646.90961.YahooMailNeo@web171206.mail.ir2.yahoo.com> Hi, Just wondering if anyone knows of a piece of software that can show a 0-55MHz wideband waterfall display with Hermes etc? I know Kiss Konsole and CuSDR have a wideband pan-adapter, but not a waterfall as far as I know. Thanks, Andrew G4XZL -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvh.net at gmail.com Tue Aug 19 13:09:40 2014 From: hvh.net at gmail.com (Hermann) Date: Tue, 19 Aug 2014 22:09:40 +0200 Subject: [hpsdr] Wideband waterfall display In-Reply-To: <1408478646.90961.YahooMailNeo@web171206.mail.ir2.yahoo.com> References: <1408478646.90961.YahooMailNeo@web171206.mail.ir2.yahoo.com> Message-ID: Hi Andrew, Next version of cuSDR has a wideband waterfall display. In the beta this is already working. 73, Hermann DL3HVH Sent from my Nexus 5 On Aug 19, 2014 10:04 PM, "Andrew" wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > Hi, > Just wondering if anyone knows of a piece of software that can show a > 0-55MHz wideband waterfall display with Hermes etc? > I know Kiss Konsole and CuSDR have a wideband pan-adapter, but not a > waterfall as far as I know. > Thanks, > Andrew > G4XZL > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at pharman.org Wed Aug 20 00:31:26 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 15:31:26 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. In order to open the SDR world to those with PC software skills we are in the process of developing a new SDR architecture. This architecture digitises the entire 0 to 30MHz radio spectrum in real time and passes the 'raw' samples directly to an associated computer. This computer then calculates the FFT of the raw samples and subsequently processes the result as the user requires. This is not a totally new concept since both the cuSDR and KISS Konsole software uses raw ADC samples to provide the wideband bandscope displays. However, for this requirement the FFT only needs to be done at the bandscope update rate of a few 10's of times per second, which hardly taxes a modern PC at all. The new concept requires that we take the FFT of all samples in real-time. This has been possible in the past - if you had access to a Cray super computer! Well now we do have access to very low cost computers that provide the processing power we need. One example of this is the new Nvidia Jetson TK1 single board computer. At a cost of $192 this board contains four ARM CPUs plus 192 CUDA processors. More details of this remarkable board can be found here: https://developer.nvidia.com/jetson-tk1 Since the CUDA cores can process data in parallel, we can use these to perform the high speed FFT. John, G0ORX, has written preliminary code for the Jetson board and has confirmed that it has the necessary performance we require. The test environment consisted of a Jetson board connected via Gigabit Ethernet to an Angelia board. A special version of FPGA code was written for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the Jetson board. We used raw Ethernet frames over the Gigabit link, in order to maximise the link bandwidth, since we require a sustained 983Mbps transfer rate. Whilst it's still early days, and there is much more to be done, this critical early success does indicate that this new architecture has a very promising future. The Jetson board is taking the role of an 'SDR Server' which I have written about in the past. In which case what benefits does this new architecture provide to openHPSR? 1. The FPGA code is greatly simplified, is easier to write and maintain, and hence uses a small percentage of the space available with a subsequent reduction in power consumption. 2. The protocol between the SDR hardware and the SDR Server is greatly simplified since the SDR hardware only has to connect to a single, dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer required. The SDR Server simply needs to know the MAC address of the SDR hardware in order to communicate. It should be possible for a single SDR hardware board to feed multiple SDR Servers, but that's something for the future. 3. Virtually all the signal processing is undertaken on the associated single board computer (SBC) or (suitable) PC. If sufficient processing power is available then the GUI can run on the same SBC. Alternatively the user's normal PC (which does not require to be high performance since it does not do any significant digital signal processing) or a Tablet, cell phone etc could be used. 4. Many more users have the necessary skills and experience to support, maintain and further develop the code. New features are added to the SDR Server code rather than the FPGA code. 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA and/or power supply restrictions may have limited adding new features. 6. Future hardware upgrades will be to the associated SBC where faster and lower cost options can be expected. Nvidia have already indicated that a 64 bit board will be available in the near future. 7. Remote access to an SDR via the Internet will enable multiple users to share the SDR with each selecting their desired frequency, bandwidth and mode. There are other potential benefits relating to simpler and lower cost SDR hardware, but that is for the future. For want of a name we are calling this new architecture 'Direct Fourier Conversion' (DFC). For those that are already experimenting with the Jetson board we do intend to release the DFC FPGA code for both Angelia and Hermes boards and I will advise when, and where, this is available. John's code is presently not available, so please don't pester him, but as soon as it reaches Beta stage it will be released. Please join me in congratulating John on this exciting development. 73 Phil....VK6PH 1408519886.0 From chris at vspl.co.uk Wed Aug 20 00:42:58 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 08:42:58 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <20140820074302.6AB7048864@diego.dreamhost.com> Hi Phil I had a feeling, when I saw your paper and Hermann's at Friedrischafen, that DFC was the way things were going. Which is why I jumped on the TK1 bandwagon. Will there ever be a way of using the Mercury front end to supply the raw packets, perhaps with a bespoke daughter board? Congrats to John whom I had the pleasure of speaking to at Friedrischafen. I'm sure we all look forward to the new era of SDR in the amateur radio arena. Cheers & 73 Chris G4NUX On 20 Aug 2014, at 08:31, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408520578.0 From roland.etienne at free.fr Wed Aug 20 00:48:52 2014 From: roland.etienne at free.fr (Roland Etienne) Date: Wed, 20 Aug 2014 09:48:52 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <0EDA19C686524970B4E75CD8483127AE@F8CHKAtom> Hi Phil, Very exciting news! Congrats to John and all of you, crazy programmers! how do you find the time to do all that job ?? Thanks a lot for the fun you're giving us! 73, Roland F8CHK > -----Message d'origine----- > De?: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] De la part de Phil > Harman > Envoy??: mercredi 20 ao?t 2014 09:31 > ??: hpsdr at lists.openhpsdr.org > Objet?: [hpsdr] openHPSDR at the forefront of SDR development > > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > .... > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > .... > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr- > openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408520932.0 From phil at pharman.org Wed Aug 20 01:22:48 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 16:22:48 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: Hi Chris, The limitation of using the Mercury board together with Metis is the bandwidth of the Alex bus. If would could couple the two boards together in a suitable way then we can use the existing Mercury board. 73 Phil...VK6PH > Hi Phil > > I had a feeling, when I saw your paper and Hermann's at Friedrischafen, > that DFC was the way things were going. Which is why I jumped on the TK1 > bandwagon. > > Will there ever be a way of using the Mercury front end to supply the raw > packets, perhaps with a bespoke daughter board? > > Congrats to John whom I had the pleasure of speaking to at Friedrischafen. > I'm sure we all look forward to the new era of SDR in the amateur radio > arena. > > Cheers & 73 > > Chris G4NUX > > On 20 Aug 2014, at 08:31, Phil Harman wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> I'm delighted to be able to report that we have been able to develop, to >> proof-of-concept stage, a new SDR architecture. >> >> Current SDRs use the software equivalent of zero IF techniques, i.e. >> DDC, >> in order to provide (multiple) receivers. Whist this is quite >> effective, >> much of the initial DSP work is done using FPGAs, or a combination of >> FPGA >> plus dedicated DSP chips and microprocessors, rather than totally within >> the PC. >> >> As more complex features are added, the size and complexity of the FPGA >> and DSP code increases. The skills to write, debug and maintain this >> code >> is only available via a small percentage of software engineers, or >> enthusiasts, in comparison to those able to write code for PC based >> hardware. >> >> In order to open the SDR world to those with PC software skills we are >> in >> the process of developing a new SDR architecture. >> >> This architecture digitises the entire 0 to 30MHz radio spectrum in real >> time and passes the 'raw' samples directly to an associated computer. >> >> This computer then calculates the FFT of the raw samples and >> subsequently >> processes the result as the user requires. >> >> This is not a totally new concept since both the cuSDR and KISS Konsole >> software uses raw ADC samples to provide the wideband bandscope >> displays. >> >> However, for this requirement the FFT only needs to be done at the >> bandscope update rate of a few 10's of times per second, which hardly >> taxes a modern PC at all. >> >> The new concept requires that we take the FFT of all samples in >> real-time. >> >> This has been possible in the past - if you had access to a Cray super >> computer! >> >> Well now we do have access to very low cost computers that provide the >> processing power we need. One example of this is the new Nvidia Jetson >> TK1 single board computer. At a cost of $192 this board contains four >> ARM >> CPUs plus 192 CUDA processors. >> >> More details of this remarkable board can be found here: >> >> https://developer.nvidia.com/jetson-tk1 >> >> Since the CUDA cores can process data in parallel, we can use these to >> perform the high speed FFT. >> >> John, G0ORX, has written preliminary code for the Jetson board and has >> confirmed that it has the necessary performance we require. >> >> The test environment consisted of a Jetson board connected via Gigabit >> Ethernet to an Angelia board. A special version of FPGA code was >> written >> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >> the >> Jetson board. >> >> We used raw Ethernet frames over the Gigabit link, in order to maximise >> the link bandwidth, since we require a sustained 983Mbps transfer rate. >> >> Whilst it's still early days, and there is much more to be done, this >> critical early success does indicate that this new architecture has a >> very >> promising future. >> >> The Jetson board is taking the role of an 'SDR Server' which I have >> written about in the past. >> >> In which case what benefits does this new architecture provide to >> openHPSR? >> >> 1. The FPGA code is greatly simplified, is easier to write and maintain, >> and hence uses a small percentage of the space available with a >> subsequent >> reduction in power consumption. >> >> 2. The protocol between the SDR hardware and the SDR Server is greatly >> simplified since the SDR hardware only has to connect to a single, >> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >> required. The SDR Server simply needs to know the MAC address of the >> SDR >> hardware in order to communicate. It should be possible for a single >> SDR >> hardware board to feed multiple SDR Servers, but that's something for >> the >> future. >> >> 3. Virtually all the signal processing is undertaken on the associated >> single board computer (SBC) or (suitable) PC. If sufficient processing >> power is available then the GUI can run on the same SBC. Alternatively >> the >> user's normal PC (which does not require to be high performance since it >> does not do any significant digital signal processing) or a Tablet, cell >> phone etc could be used. >> >> 4. Many more users have the necessary skills and experience to support, >> maintain and further develop the code. New features are added to the SDR >> Server code rather than the FPGA code. >> >> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >> FPGA >> and/or power supply restrictions may have limited adding new features. >> >> 6. Future hardware upgrades will be to the associated SBC where faster >> and >> lower cost options can be expected. Nvidia have already indicated that >> a >> 64 bit board will be available in the near future. >> >> 7. Remote access to an SDR via the Internet will enable multiple users >> to >> share the SDR with each selecting their desired frequency, bandwidth and >> mode. >> >> There are other potential benefits relating to simpler and lower cost >> SDR >> hardware, but that is for the future. >> >> For want of a name we are calling this new architecture 'Direct Fourier >> Conversion' (DFC). >> >> For those that are already experimenting with the Jetson board we do >> intend to release the DFC FPGA code for both Angelia and Hermes boards >> and >> I will advise when, and where, this is available. >> >> John's code is presently not available, so please don't pester him, but >> as >> soon as it reaches Beta stage it will be released. >> >> Please join me in congratulating John on this exciting development. >> >> 73 Phil....VK6PH >> >> >> >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > 1408522968.0 From dc6ny at gmx.de Wed Aug 20 01:48:31 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Wed, 20 Aug 2014 10:48:31 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <000001cfbc53$85bf7be0$913e73a0$@de> Hi Phil, Congratulations. Maybe a stupid question: Current bottleneck is the 1 Gbit/s LAN connection that makes a decimation by factor 2 necessary or limits the frequency range to 33MHz, i.e. we lose 6m band at least as raw I/Q. Is there no (economic) way to get the LAN connection faster? 14 and 16 Bit ADC/DACs are getting faster and low-jitter sampling oscillators up to 300MHz are available, hence a lot of nice applications are imaginable, hi. 73, Helmut, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von Phil Harman Gesendet: Mittwoch, 20. August 2014 09:31 An: hpsdr at lists.openhpsdr.org Betreff: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. In order to open the SDR world to those with PC software skills we are in the process of developing a new SDR architecture. This architecture digitises the entire 0 to 30MHz radio spectrum in real time and passes the 'raw' samples directly to an associated computer. This computer then calculates the FFT of the raw samples and subsequently processes the result as the user requires. This is not a totally new concept since both the cuSDR and KISS Konsole software uses raw ADC samples to provide the wideband bandscope displays. However, for this requirement the FFT only needs to be done at the bandscope update rate of a few 10's of times per second, which hardly taxes a modern PC at all. The new concept requires that we take the FFT of all samples in real-time. This has been possible in the past - if you had access to a Cray super computer! Well now we do have access to very low cost computers that provide the processing power we need. One example of this is the new Nvidia Jetson TK1 single board computer. At a cost of $192 this board contains four ARM CPUs plus 192 CUDA processors. More details of this remarkable board can be found here: https://developer.nvidia.com/jetson-tk1 Since the CUDA cores can process data in parallel, we can use these to perform the high speed FFT. John, G0ORX, has written preliminary code for the Jetson board and has confirmed that it has the necessary performance we require. The test environment consisted of a Jetson board connected via Gigabit Ethernet to an Angelia board. A special version of FPGA code was written for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the Jetson board. We used raw Ethernet frames over the Gigabit link, in order to maximise the link bandwidth, since we require a sustained 983Mbps transfer rate. Whilst it's still early days, and there is much more to be done, this critical early success does indicate that this new architecture has a very promising future. The Jetson board is taking the role of an 'SDR Server' which I have written about in the past. In which case what benefits does this new architecture provide to openHPSR? 1. The FPGA code is greatly simplified, is easier to write and maintain, and hence uses a small percentage of the space available with a subsequent reduction in power consumption. 2. The protocol between the SDR hardware and the SDR Server is greatly simplified since the SDR hardware only has to connect to a single, dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer required. The SDR Server simply needs to know the MAC address of the SDR hardware in order to communicate. It should be possible for a single SDR hardware board to feed multiple SDR Servers, but that's something for the future. 3. Virtually all the signal processing is undertaken on the associated single board computer (SBC) or (suitable) PC. If sufficient processing power is available then the GUI can run on the same SBC. Alternatively the user's normal PC (which does not require to be high performance since it does not do any significant digital signal processing) or a Tablet, cell phone etc could be used. 4. Many more users have the necessary skills and experience to support, maintain and further develop the code. New features are added to the SDR Server code rather than the FPGA code. 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA and/or power supply restrictions may have limited adding new features. 6. Future hardware upgrades will be to the associated SBC where faster and lower cost options can be expected. Nvidia have already indicated that a 64 bit board will be available in the near future. 7. Remote access to an SDR via the Internet will enable multiple users to share the SDR with each selecting their desired frequency, bandwidth and mode. There are other potential benefits relating to simpler and lower cost SDR hardware, but that is for the future. For want of a name we are calling this new architecture 'Direct Fourier Conversion' (DFC). For those that are already experimenting with the Jetson board we do intend to release the DFC FPGA code for both Angelia and Hermes boards and I will advise when, and where, this is available. John's code is presently not available, so please don't pester him, but as soon as it reaches Beta stage it will be released. Please join me in congratulating John on this exciting development. 73 Phil....VK6PH _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408524511.0 From chris at vspl.co.uk Wed Aug 20 01:48:56 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 09:48:56 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <20140820084900.495FC4861E@diego.dreamhost.com> Hi Phil I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) Cheers Chris On 20 Aug 2014, at 09:22, "Phil Harman" wrote: > Hi Chris, > > The limitation of using the Mercury board together with Metis is the > bandwidth of the Alex bus. > > If would could couple the two boards together in a suitable way then we > can use the existing Mercury board. > > 73 Phil...VK6PH > > >> Hi Phil >> >> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >> that DFC was the way things were going. Which is why I jumped on the TK1 >> bandwagon. >> >> Will there ever be a way of using the Mercury front end to supply the raw >> packets, perhaps with a bespoke daughter board? >> >> Congrats to John whom I had the pleasure of speaking to at Friedrischafen. >> I'm sure we all look forward to the new era of SDR in the amateur radio >> arena. >> >> Cheers & 73 >> >> Chris G4NUX >> >> On 20 Aug 2014, at 08:31, Phil Harman wrote: >> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> All, >>> >>> I'm delighted to be able to report that we have been able to develop, to >>> proof-of-concept stage, a new SDR architecture. >>> >>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>> DDC, >>> in order to provide (multiple) receivers. Whist this is quite >>> effective, >>> much of the initial DSP work is done using FPGAs, or a combination of >>> FPGA >>> plus dedicated DSP chips and microprocessors, rather than totally within >>> the PC. >>> >>> As more complex features are added, the size and complexity of the FPGA >>> and DSP code increases. The skills to write, debug and maintain this >>> code >>> is only available via a small percentage of software engineers, or >>> enthusiasts, in comparison to those able to write code for PC based >>> hardware. >>> >>> In order to open the SDR world to those with PC software skills we are >>> in >>> the process of developing a new SDR architecture. >>> >>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>> time and passes the 'raw' samples directly to an associated computer. >>> >>> This computer then calculates the FFT of the raw samples and >>> subsequently >>> processes the result as the user requires. >>> >>> This is not a totally new concept since both the cuSDR and KISS Konsole >>> software uses raw ADC samples to provide the wideband bandscope >>> displays. >>> >>> However, for this requirement the FFT only needs to be done at the >>> bandscope update rate of a few 10's of times per second, which hardly >>> taxes a modern PC at all. >>> >>> The new concept requires that we take the FFT of all samples in >>> real-time. >>> >>> This has been possible in the past - if you had access to a Cray super >>> computer! >>> >>> Well now we do have access to very low cost computers that provide the >>> processing power we need. One example of this is the new Nvidia Jetson >>> TK1 single board computer. At a cost of $192 this board contains four >>> ARM >>> CPUs plus 192 CUDA processors. >>> >>> More details of this remarkable board can be found here: >>> >>> https://developer.nvidia.com/jetson-tk1 >>> >>> Since the CUDA cores can process data in parallel, we can use these to >>> perform the high speed FFT. >>> >>> John, G0ORX, has written preliminary code for the Jetson board and has >>> confirmed that it has the necessary performance we require. >>> >>> The test environment consisted of a Jetson board connected via Gigabit >>> Ethernet to an Angelia board. A special version of FPGA code was >>> written >>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>> the >>> Jetson board. >>> >>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>> >>> Whilst it's still early days, and there is much more to be done, this >>> critical early success does indicate that this new architecture has a >>> very >>> promising future. >>> >>> The Jetson board is taking the role of an 'SDR Server' which I have >>> written about in the past. >>> >>> In which case what benefits does this new architecture provide to >>> openHPSR? >>> >>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>> and hence uses a small percentage of the space available with a >>> subsequent >>> reduction in power consumption. >>> >>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>> simplified since the SDR hardware only has to connect to a single, >>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>> required. The SDR Server simply needs to know the MAC address of the >>> SDR >>> hardware in order to communicate. It should be possible for a single >>> SDR >>> hardware board to feed multiple SDR Servers, but that's something for >>> the >>> future. >>> >>> 3. Virtually all the signal processing is undertaken on the associated >>> single board computer (SBC) or (suitable) PC. If sufficient processing >>> power is available then the GUI can run on the same SBC. Alternatively >>> the >>> user's normal PC (which does not require to be high performance since it >>> does not do any significant digital signal processing) or a Tablet, cell >>> phone etc could be used. >>> >>> 4. Many more users have the necessary skills and experience to support, >>> maintain and further develop the code. New features are added to the SDR >>> Server code rather than the FPGA code. >>> >>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>> FPGA >>> and/or power supply restrictions may have limited adding new features. >>> >>> 6. Future hardware upgrades will be to the associated SBC where faster >>> and >>> lower cost options can be expected. Nvidia have already indicated that >>> a >>> 64 bit board will be available in the near future. >>> >>> 7. Remote access to an SDR via the Internet will enable multiple users >>> to >>> share the SDR with each selecting their desired frequency, bandwidth and >>> mode. >>> >>> There are other potential benefits relating to simpler and lower cost >>> SDR >>> hardware, but that is for the future. >>> >>> For want of a name we are calling this new architecture 'Direct Fourier >>> Conversion' (DFC). >>> >>> For those that are already experimenting with the Jetson board we do >>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>> and >>> I will advise when, and where, this is available. >>> >>> John's code is presently not available, so please don't pester him, but >>> as >>> soon as it reaches Beta stage it will be released. >>> >>> Please join me in congratulating John on this exciting development. >>> >>> 73 Phil....VK6PH >>> >>> >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: >>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> >> > 1408524536.0 From meijer.ha at home.nl Wed Aug 20 01:58:26 2014 From: meijer.ha at home.nl (H.A.Meijer) Date: Wed, 20 Aug 2014 10:58:26 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F46332.9040601@home.nl> Phil Harman schreef op 20-8-2014 om 9:31: > ***** High Performance Software Defined Radio Discussion List ***** > > > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > Hi, I'm just a "end-user" and not a software engineer, so it's not very easy, for me, to understand all of this. Does it mean that that this "new board" is connected between your sdr transceiver (hermes etc) and your PC?. I would rater like a 'stand-alone' and 'High Performance' solution for better DSP functionality etc, and to get rid of my pc, then an extra board that just needs more soft- and firmware.... But I understand that this is very exiting for software engineers, so good luck. Bert PA2XHF --- Dit e-mailbericht bevat geen virussen en malware omdat avast! Antivirus-bescherming actief is. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dc6ny at gmx.de Wed Aug 20 02:09:52 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Wed, 20 Aug 2014 11:09:52 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F46332.9040601@home.nl> References: <53F46332.9040601@home.nl> Message-ID: <000c01cfbc56$808c9560$81a5c020$@de> Hi Bert, please see Phil's presentation 'Further prospective of HPSDR' at http://openhpsdr.org/publications.php and you will collect a lot of important info. 73, Helmut, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von H.A.Meijer Gesendet: Mittwoch, 20. August 2014 10:58 An: hpsdr at lists.openhpsdr.org Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** 1408525792.0 From ksyverud at broadpark.no Wed Aug 20 02:51:45 2014 From: ksyverud at broadpark.no (Kjell Syverud) Date: Wed, 20 Aug 2014 11:51:45 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F46FB1.2050304@broadpark.no> Hi Phil. Nice to hear you can confirm the "DFC" as you presented it in Friedrichshafen. One question, may be you commented it in Friedrichshafen, but i can not remember: Will it be possible to cover 30 to 60 MHz ? 73 LA9CY/Kjell 1408528305.0 From phil at pharman.org Wed Aug 20 04:15:36 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 19:15:36 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F46332.9040601@home.nl> References: <53F46332.9040601@home.nl> Message-ID: <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> Hi Bert, Yes, as we are today the ?new board? is connected between your SDR hardware and your PC. It may be possible to run both the SDR server and Client GUI software on the one SBC or PC. Its a little early yet to know if the Jetson board is capable of doing this. If so, then with your SDR hardware you would have a dedicated SDR that does not require an additional PC. This could all be packaged into a case with a suitable touch screen etc. You can always do that today by using a suitable SBC that will run Windows. 73 Phil...VK6PH Hi, I'm just a "end-user" and not a software engineer, so it's not very easy, for me, to understand all of this. Does it mean that that this "new board" is connected between your sdr transceiver (hermes etc) and your PC?. I would rater like a 'stand-alone' and 'High Performance' solution for better DSP functionality etc, and to get rid of my pc, then an extra board that just needs more soft- and firmware.... But I understand that this is very exiting for software engineers, so good luck. Bert PA2XHF -------------------------------------------------------------------------------- Dit e-mailbericht bevat geen virussen en malware omdat avast! Antivirus actief is. -------------------------------------------------------------------------------- _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at pharman.org Wed Aug 20 04:28:08 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 19:28:08 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F46FB1.2050304@broadpark.no> References: <53F46FB1.2050304@broadpark.no> Message-ID: <0EB6587E8CAE411C8E61A6B0215E7070@ShackPC2> Hi Kjell, Initially its not going to be possible to cover 0 to 55MHz of spectrum since with 16 bits of ADC data that would exceed the capacity of the Gigabit channel. We could reduce the ADC data to 8 bits but that would hardly meet the 'High Performance' requirement! We can still use 6m since this will alias into the 0-30MHz range, but we can't do both at the same time. We still have 16Mbps 'spare' in the Ethernet bandwidth so we may be able to include 6m using a conventional DDC. Still early days, we can use the mini PCIe interface on the Jetson board to interface to the ADC/DAC in order to run at faster sampling rates. At the moment we don't know how much spare processing capacity we have on board so still lots more tests to run. 73 Phil...VK6PH -----Original Message----- From: Kjell Syverud Sent: Wednesday, August 20, 2014 5:51 PM To: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Hi Phil. Nice to hear you can confirm the "DFC" as you presented it in Friedrichshafen. One question, may be you commented it in Friedrichshafen, but i can not remember: Will it be possible to cover 30 to 60 MHz ? 73 LA9CY/Kjell _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1408534088.0 From phil at pharman.org Wed Aug 20 04:37:31 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 19:37:31 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> Hi Chris. Alternatively, you could make a small PCB that plugged into J5 on Mercury that held the PHY, 25MHz clock and Ethernet socket. Since you no longer need any DDC code in the FPGA you would have plenty of room to house the raw Ethernet code. 'Weekend Project' anyone ? 73 Phil....VK6PH -----Original Message----- From: Chris Smith Sent: Wednesday, August 20, 2014 4:48 PM To: phil at pharman.org Cc: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development Hi Phil I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) Cheers Chris On 20 Aug 2014, at 09:22, "Phil Harman" wrote: > Hi Chris, > > The limitation of using the Mercury board together with Metis is the > bandwidth of the Alex bus. > > If would could couple the two boards together in a suitable way then we > can use the existing Mercury board. > > 73 Phil...VK6PH > > >> Hi Phil >> >> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >> that DFC was the way things were going. Which is why I jumped on the TK1 >> bandwagon. >> >> Will there ever be a way of using the Mercury front end to supply the raw >> packets, perhaps with a bespoke daughter board? >> >> Congrats to John whom I had the pleasure of speaking to at >> Friedrischafen. >> I'm sure we all look forward to the new era of SDR in the amateur radio >> arena. >> >> Cheers & 73 >> >> Chris G4NUX >> >> On 20 Aug 2014, at 08:31, Phil Harman wrote: >> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> All, >>> >>> I'm delighted to be able to report that we have been able to develop, to >>> proof-of-concept stage, a new SDR architecture. >>> >>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>> DDC, >>> in order to provide (multiple) receivers. Whist this is quite >>> effective, >>> much of the initial DSP work is done using FPGAs, or a combination of >>> FPGA >>> plus dedicated DSP chips and microprocessors, rather than totally within >>> the PC. >>> >>> As more complex features are added, the size and complexity of the FPGA >>> and DSP code increases. The skills to write, debug and maintain this >>> code >>> is only available via a small percentage of software engineers, or >>> enthusiasts, in comparison to those able to write code for PC based >>> hardware. >>> >>> In order to open the SDR world to those with PC software skills we are >>> in >>> the process of developing a new SDR architecture. >>> >>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>> time and passes the 'raw' samples directly to an associated computer. >>> >>> This computer then calculates the FFT of the raw samples and >>> subsequently >>> processes the result as the user requires. >>> >>> This is not a totally new concept since both the cuSDR and KISS Konsole >>> software uses raw ADC samples to provide the wideband bandscope >>> displays. >>> >>> However, for this requirement the FFT only needs to be done at the >>> bandscope update rate of a few 10's of times per second, which hardly >>> taxes a modern PC at all. >>> >>> The new concept requires that we take the FFT of all samples in >>> real-time. >>> >>> This has been possible in the past - if you had access to a Cray super >>> computer! >>> >>> Well now we do have access to very low cost computers that provide the >>> processing power we need. One example of this is the new Nvidia Jetson >>> TK1 single board computer. At a cost of $192 this board contains four >>> ARM >>> CPUs plus 192 CUDA processors. >>> >>> More details of this remarkable board can be found here: >>> >>> https://developer.nvidia.com/jetson-tk1 >>> >>> Since the CUDA cores can process data in parallel, we can use these to >>> perform the high speed FFT. >>> >>> John, G0ORX, has written preliminary code for the Jetson board and has >>> confirmed that it has the necessary performance we require. >>> >>> The test environment consisted of a Jetson board connected via Gigabit >>> Ethernet to an Angelia board. A special version of FPGA code was >>> written >>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>> the >>> Jetson board. >>> >>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>> >>> Whilst it's still early days, and there is much more to be done, this >>> critical early success does indicate that this new architecture has a >>> very >>> promising future. >>> >>> The Jetson board is taking the role of an 'SDR Server' which I have >>> written about in the past. >>> >>> In which case what benefits does this new architecture provide to >>> openHPSR? >>> >>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>> and hence uses a small percentage of the space available with a >>> subsequent >>> reduction in power consumption. >>> >>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>> simplified since the SDR hardware only has to connect to a single, >>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>> required. The SDR Server simply needs to know the MAC address of the >>> SDR >>> hardware in order to communicate. It should be possible for a single >>> SDR >>> hardware board to feed multiple SDR Servers, but that's something for >>> the >>> future. >>> >>> 3. Virtually all the signal processing is undertaken on the associated >>> single board computer (SBC) or (suitable) PC. If sufficient processing >>> power is available then the GUI can run on the same SBC. Alternatively >>> the >>> user's normal PC (which does not require to be high performance since it >>> does not do any significant digital signal processing) or a Tablet, cell >>> phone etc could be used. >>> >>> 4. Many more users have the necessary skills and experience to support, >>> maintain and further develop the code. New features are added to the SDR >>> Server code rather than the FPGA code. >>> >>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>> FPGA >>> and/or power supply restrictions may have limited adding new features. >>> >>> 6. Future hardware upgrades will be to the associated SBC where faster >>> and >>> lower cost options can be expected. Nvidia have already indicated that >>> a >>> 64 bit board will be available in the near future. >>> >>> 7. Remote access to an SDR via the Internet will enable multiple users >>> to >>> share the SDR with each selecting their desired frequency, bandwidth and >>> mode. >>> >>> There are other potential benefits relating to simpler and lower cost >>> SDR >>> hardware, but that is for the future. >>> >>> For want of a name we are calling this new architecture 'Direct Fourier >>> Conversion' (DFC). >>> >>> For those that are already experimenting with the Jetson board we do >>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>> and >>> I will advise when, and where, this is available. >>> >>> John's code is presently not available, so please don't pester him, but >>> as >>> soon as it reaches Beta stage it will be released. >>> >>> Please join me in congratulating John on this exciting development. >>> >>> 73 Phil....VK6PH >>> >>> >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: >>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> >> > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1408534651.0 From jeffrie at talktalk.net Wed Aug 20 06:25:58 2014 From: jeffrie at talktalk.net (Jeff Cook) Date: Wed, 20 Aug 2014 14:25:58 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <000001cfbc7a$47ce2d00$d76a8700$@talktalk.net> Hello Phil, As the epitome of what is an end user, button pusher, knob twiddler, et cetera, I readily admit to understanding little of which you speak, but your enthusiasm is infectious and your excitement palpable. I am still back in the days of Mercury and Ozymandias and love every minute of it, so thank you to you, and John, and all the others that are the true exponents of the radio art. It really is a pleasure being on board this particular magic of radio train, even though I have no idea where it's going. Jeff, G0AFQ. -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vrf at johnc57uk.plus.com Wed Aug 20 06:54:16 2014 From: g3vrf at johnc57uk.plus.com (G3VRF) Date: Wed, 20 Aug 2014 14:54:16 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <53F4A888.10302@johnc57uk.plus.com> Hi Phil et al, Having been around in Ham radio for a good long while now, I have seen many changes and advancements in the hobby over the many years but none as exciting as this. I would like to echo Jeff's sentiments G0AFQ, and express how sincerely grateful I am to yourself Phil, and all the others who have contributed to the HPSDR project and from whom I've benefited. I have a Hermes board and homebrew low power PA which works extremely well and is a pleasure to use. In my view it easily out performs my Yaesu and Icom transceivers on receive. When I complete the high power PA it will no doubt out perfom on tx as well. I have earwigged on the side for a long while now monitoring developments and comments with interest. Next step is to purchase a Jetson TK1 SBC and attempt to build cuSDR on that. Again my heartfelt thanks. 73s John G3VRF 1408542856.0 From chris at vspl.co.uk Wed Aug 20 07:12:21 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 15:12:21 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> References: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> Message-ID: <20140820141226.1ED8248937@diego.dreamhost.com> Hi Phil Not sure you meant J5 - that seems to be the I2C data bypass jumper. J9 HDR 5P TEST seems to have some interesting/useful I/O pins. Is that what you meant? 73 Chris G4NUX On 20 Aug 2014, at 12:37, Phil Harman wrote: > Hi Chris. > > Alternatively, you could make a small PCB that plugged into J5 on Mercury that held the PHY, 25MHz clock and Ethernet socket. Since you no longer need any DDC code in the FPGA you would have plenty of room to house the raw Ethernet code. > > 'Weekend Project' anyone ? > > 73 Phil....VK6PH > > > > > > -----Original Message----- From: Chris Smith > Sent: Wednesday, August 20, 2014 4:48 PM > To: phil at pharman.org > Cc: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > Hi Phil > > I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) > > Cheers > > Chris > > > On 20 Aug 2014, at 09:22, "Phil Harman" wrote: > >> Hi Chris, >> >> The limitation of using the Mercury board together with Metis is the >> bandwidth of the Alex bus. >> >> If would could couple the two boards together in a suitable way then we >> can use the existing Mercury board. >> >> 73 Phil...VK6PH >> >> >>> Hi Phil >>> >>> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >>> that DFC was the way things were going. Which is why I jumped on the TK1 >>> bandwagon. >>> >>> Will there ever be a way of using the Mercury front end to supply the raw >>> packets, perhaps with a bespoke daughter board? >>> >>> Congrats to John whom I had the pleasure of speaking to at Friedrischafen. >>> I'm sure we all look forward to the new era of SDR in the amateur radio >>> arena. >>> >>> Cheers & 73 >>> >>> Chris G4NUX >>> >>> On 20 Aug 2014, at 08:31, Phil Harman wrote: >>> >>>> ***** High Performance Software Defined Radio Discussion List ***** >>>> >>>> All, >>>> >>>> I'm delighted to be able to report that we have been able to develop, to >>>> proof-of-concept stage, a new SDR architecture. >>>> >>>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>>> DDC, >>>> in order to provide (multiple) receivers. Whist this is quite >>>> effective, >>>> much of the initial DSP work is done using FPGAs, or a combination of >>>> FPGA >>>> plus dedicated DSP chips and microprocessors, rather than totally within >>>> the PC. >>>> >>>> As more complex features are added, the size and complexity of the FPGA >>>> and DSP code increases. The skills to write, debug and maintain this >>>> code >>>> is only available via a small percentage of software engineers, or >>>> enthusiasts, in comparison to those able to write code for PC based >>>> hardware. >>>> >>>> In order to open the SDR world to those with PC software skills we are >>>> in >>>> the process of developing a new SDR architecture. >>>> >>>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>>> time and passes the 'raw' samples directly to an associated computer. >>>> >>>> This computer then calculates the FFT of the raw samples and >>>> subsequently >>>> processes the result as the user requires. >>>> >>>> This is not a totally new concept since both the cuSDR and KISS Konsole >>>> software uses raw ADC samples to provide the wideband bandscope >>>> displays. >>>> >>>> However, for this requirement the FFT only needs to be done at the >>>> bandscope update rate of a few 10's of times per second, which hardly >>>> taxes a modern PC at all. >>>> >>>> The new concept requires that we take the FFT of all samples in >>>> real-time. >>>> >>>> This has been possible in the past - if you had access to a Cray super >>>> computer! >>>> >>>> Well now we do have access to very low cost computers that provide the >>>> processing power we need. One example of this is the new Nvidia Jetson >>>> TK1 single board computer. At a cost of $192 this board contains four >>>> ARM >>>> CPUs plus 192 CUDA processors. >>>> >>>> More details of this remarkable board can be found here: >>>> >>>> https://developer.nvidia.com/jetson-tk1 >>>> >>>> Since the CUDA cores can process data in parallel, we can use these to >>>> perform the high speed FFT. >>>> >>>> John, G0ORX, has written preliminary code for the Jetson board and has >>>> confirmed that it has the necessary performance we require. >>>> >>>> The test environment consisted of a Jetson board connected via Gigabit >>>> Ethernet to an Angelia board. A special version of FPGA code was >>>> written >>>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>>> the >>>> Jetson board. >>>> >>>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>>> >>>> Whilst it's still early days, and there is much more to be done, this >>>> critical early success does indicate that this new architecture has a >>>> very >>>> promising future. >>>> >>>> The Jetson board is taking the role of an 'SDR Server' which I have >>>> written about in the past. >>>> >>>> In which case what benefits does this new architecture provide to >>>> openHPSR? >>>> >>>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>>> and hence uses a small percentage of the space available with a >>>> subsequent >>>> reduction in power consumption. >>>> >>>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>>> simplified since the SDR hardware only has to connect to a single, >>>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>>> required. The SDR Server simply needs to know the MAC address of the >>>> SDR >>>> hardware in order to communicate. It should be possible for a single >>>> SDR >>>> hardware board to feed multiple SDR Servers, but that's something for >>>> the >>>> future. >>>> >>>> 3. Virtually all the signal processing is undertaken on the associated >>>> single board computer (SBC) or (suitable) PC. If sufficient processing >>>> power is available then the GUI can run on the same SBC. Alternatively >>>> the >>>> user's normal PC (which does not require to be high performance since it >>>> does not do any significant digital signal processing) or a Tablet, cell >>>> phone etc could be used. >>>> >>>> 4. Many more users have the necessary skills and experience to support, >>>> maintain and further develop the code. New features are added to the SDR >>>> Server code rather than the FPGA code. >>>> >>>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>>> FPGA >>>> and/or power supply restrictions may have limited adding new features. >>>> >>>> 6. Future hardware upgrades will be to the associated SBC where faster >>>> and >>>> lower cost options can be expected. Nvidia have already indicated that >>>> a >>>> 64 bit board will be available in the near future. >>>> >>>> 7. Remote access to an SDR via the Internet will enable multiple users >>>> to >>>> share the SDR with each selecting their desired frequency, bandwidth and >>>> mode. >>>> >>>> There are other potential benefits relating to simpler and lower cost >>>> SDR >>>> hardware, but that is for the future. >>>> >>>> For want of a name we are calling this new architecture 'Direct Fourier >>>> Conversion' (DFC). >>>> >>>> For those that are already experimenting with the Jetson board we do >>>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>>> and >>>> I will advise when, and where, this is available. >>>> >>>> John's code is presently not available, so please don't pester him, but >>>> as >>>> soon as it reaches Beta stage it will be released. >>>> >>>> Please join me in congratulating John on this exciting development. >>>> >>>> 73 Phil....VK6PH >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> HPSDR Discussion List >>>> To post msg: hpsdr at openhpsdr.org >>>> Subscription help: >>>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>>> HPSDR web page: http://openhpsdr.org >>>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >>> >>> >>> >> > > > --- > This email is free from viruses and malware because avast! Antivirus protection is active. > http://www.avast.com 1408543941.0 From chris at vspl.co.uk Wed Aug 20 07:19:06 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 15:19:06 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <20140820141226.1ED8248937@diego.dreamhost.com> References: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> <20140820141226.1ED8248937@diego.dreamhost.com> Message-ID: <20140820141910.E5D7A489DF@diego.dreamhost.com> Whoops! No, I need to get some new glasses. J5 20-pin header has a whole bunch of good stuff on it. Sorry. 73 Chris G4NUX On 20 Aug 2014, at 15:12, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Phil > > Not sure you meant J5 - that seems to be the I2C data bypass jumper. J9 HDR 5P TEST seems to have some interesting/useful I/O pins. Is that what you meant? > > 73 Chris G4NUX > > On 20 Aug 2014, at 12:37, Phil Harman wrote: > >> Hi Chris. >> >> Alternatively, you could make a small PCB that plugged into J5 on Mercury that held the PHY, 25MHz clock and Ethernet socket. Since you no longer need any DDC code in the FPGA you would have plenty of room to house the raw Ethernet code. >> >> 'Weekend Project' anyone ? >> >> 73 Phil....VK6PH >> >> >> >> >> >> -----Original Message----- From: Chris Smith >> Sent: Wednesday, August 20, 2014 4:48 PM >> To: phil at pharman.org >> Cc: hpsdr at lists.openhpsdr.org >> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >> >> Hi Phil >> >> I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) >> >> Cheers >> >> Chris >> >> >> On 20 Aug 2014, at 09:22, "Phil Harman" wrote: >> >>> Hi Chris, >>> >>> The limitation of using the Mercury board together with Metis is the >>> bandwidth of the Alex bus. >>> >>> If would could couple the two boards together in a suitable way then we >>> can use the existing Mercury board. >>> >>> 73 Phil...VK6PH >>> >>> >>>> Hi Phil >>>> >>>> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >>>> that DFC was the way things were going. Which is why I jumped on the TK1 >>>> bandwagon. >>>> >>>> Will there ever be a way of using the Mercury front end to supply the raw >>>> packets, perhaps with a bespoke daughter board? >>>> >>>> Congrats to John whom I had the pleasure of speaking to at Friedrischafen. >>>> I'm sure we all look forward to the new era of SDR in the amateur radio >>>> arena. >>>> >>>> Cheers & 73 >>>> >>>> Chris G4NUX >>>> >>>> On 20 Aug 2014, at 08:31, Phil Harman wrote: >>>> >>>>> ***** High Performance Software Defined Radio Discussion List ***** >>>>> >>>>> All, >>>>> >>>>> I'm delighted to be able to report that we have been able to develop, to >>>>> proof-of-concept stage, a new SDR architecture. >>>>> >>>>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>>>> DDC, >>>>> in order to provide (multiple) receivers. Whist this is quite >>>>> effective, >>>>> much of the initial DSP work is done using FPGAs, or a combination of >>>>> FPGA >>>>> plus dedicated DSP chips and microprocessors, rather than totally within >>>>> the PC. >>>>> >>>>> As more complex features are added, the size and complexity of the FPGA >>>>> and DSP code increases. The skills to write, debug and maintain this >>>>> code >>>>> is only available via a small percentage of software engineers, or >>>>> enthusiasts, in comparison to those able to write code for PC based >>>>> hardware. >>>>> >>>>> In order to open the SDR world to those with PC software skills we are >>>>> in >>>>> the process of developing a new SDR architecture. >>>>> >>>>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>>>> time and passes the 'raw' samples directly to an associated computer. >>>>> >>>>> This computer then calculates the FFT of the raw samples and >>>>> subsequently >>>>> processes the result as the user requires. >>>>> >>>>> This is not a totally new concept since both the cuSDR and KISS Konsole >>>>> software uses raw ADC samples to provide the wideband bandscope >>>>> displays. >>>>> >>>>> However, for this requirement the FFT only needs to be done at the >>>>> bandscope update rate of a few 10's of times per second, which hardly >>>>> taxes a modern PC at all. >>>>> >>>>> The new concept requires that we take the FFT of all samples in >>>>> real-time. >>>>> >>>>> This has been possible in the past - if you had access to a Cray super >>>>> computer! >>>>> >>>>> Well now we do have access to very low cost computers that provide the >>>>> processing power we need. One example of this is the new Nvidia Jetson >>>>> TK1 single board computer. At a cost of $192 this board contains four >>>>> ARM >>>>> CPUs plus 192 CUDA processors. >>>>> >>>>> More details of this remarkable board can be found here: >>>>> >>>>> https://developer.nvidia.com/jetson-tk1 >>>>> >>>>> Since the CUDA cores can process data in parallel, we can use these to >>>>> perform the high speed FFT. >>>>> >>>>> John, G0ORX, has written preliminary code for the Jetson board and has >>>>> confirmed that it has the necessary performance we require. >>>>> >>>>> The test environment consisted of a Jetson board connected via Gigabit >>>>> Ethernet to an Angelia board. A special version of FPGA code was >>>>> written >>>>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>>>> the >>>>> Jetson board. >>>>> >>>>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>>>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>>>> >>>>> Whilst it's still early days, and there is much more to be done, this >>>>> critical early success does indicate that this new architecture has a >>>>> very >>>>> promising future. >>>>> >>>>> The Jetson board is taking the role of an 'SDR Server' which I have >>>>> written about in the past. >>>>> >>>>> In which case what benefits does this new architecture provide to >>>>> openHPSR? >>>>> >>>>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>>>> and hence uses a small percentage of the space available with a >>>>> subsequent >>>>> reduction in power consumption. >>>>> >>>>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>>>> simplified since the SDR hardware only has to connect to a single, >>>>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>>>> required. The SDR Server simply needs to know the MAC address of the >>>>> SDR >>>>> hardware in order to communicate. It should be possible for a single >>>>> SDR >>>>> hardware board to feed multiple SDR Servers, but that's something for >>>>> the >>>>> future. >>>>> >>>>> 3. Virtually all the signal processing is undertaken on the associated >>>>> single board computer (SBC) or (suitable) PC. If sufficient processing >>>>> power is available then the GUI can run on the same SBC. Alternatively >>>>> the >>>>> user's normal PC (which does not require to be high performance since it >>>>> does not do any significant digital signal processing) or a Tablet, cell >>>>> phone etc could be used. >>>>> >>>>> 4. Many more users have the necessary skills and experience to support, >>>>> maintain and further develop the code. New features are added to the SDR >>>>> Server code rather than the FPGA code. >>>>> >>>>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>>>> FPGA >>>>> and/or power supply restrictions may have limited adding new features. >>>>> >>>>> 6. Future hardware upgrades will be to the associated SBC where faster >>>>> and >>>>> lower cost options can be expected. Nvidia have already indicated that >>>>> a >>>>> 64 bit board will be available in the near future. >>>>> >>>>> 7. Remote access to an SDR via the Internet will enable multiple users >>>>> to >>>>> share the SDR with each selecting their desired frequency, bandwidth and >>>>> mode. >>>>> >>>>> There are other potential benefits relating to simpler and lower cost >>>>> SDR >>>>> hardware, but that is for the future. >>>>> >>>>> For want of a name we are calling this new architecture 'Direct Fourier >>>>> Conversion' (DFC). >>>>> >>>>> For those that are already experimenting with the Jetson board we do >>>>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>>>> and >>>>> I will advise when, and where, this is available. >>>>> >>>>> John's code is presently not available, so please don't pester him, but >>>>> as >>>>> soon as it reaches Beta stage it will be released. >>>>> >>>>> Please join me in congratulating John on this exciting development. >>>>> >>>>> 73 Phil....VK6PH >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> HPSDR Discussion List >>>>> To post msg: hpsdr at openhpsdr.org >>>>> Subscription help: >>>>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>>>> HPSDR web page: http://openhpsdr.org >>>>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >>>> >>>> >>>> >>> >> >> >> --- >> This email is free from viruses and malware because avast! Antivirus protection is active. >> http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408544346.0 From mark at buttery.org Wed Aug 20 07:20:53 2014 From: mark at buttery.org (=?UTF-8?B?U2hpcmxleSBNw6FycXVleiBEw7psY2V5?=) Date: Wed, 20 Aug 2014 10:20:53 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <000001cfbc53$85bf7be0$913e73a0$@de> References: <000001cfbc53$85bf7be0$913e73a0$@de> Message-ID: > Congratulations. Maybe a stupid question: Current bottleneck is the 1 Gbit/s > LAN connection that makes a decimation by factor 2 necessary or limits the > frequency range to 33MHz, i.e. we lose 6m band at least as raw I/Q. Is > there no (economic) way to get the LAN connection faster? 14 and 16 Bit > ADC/DACs are getting faster and low-jitter sampling oscillators up to 300MHz > are available, hence a lot of nice applications are imaginable, hi. With the current boards there may not be. But a variety of standardized higher speed interfaces are available, including eSATA, Thunderbolt, USB 3.0, and 10G Ethernet. A future design could move to one of those. 1408544453.0 From meijer.ha at home.nl Wed Aug 20 08:29:00 2014 From: meijer.ha at home.nl (H.A.Meijer) Date: Wed, 20 Aug 2014 17:29:00 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> References: <53F46332.9040601@home.nl> <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> Message-ID: <53F4BEBC.9080105@home.nl> Hi Phil, So, just to simplify, so that I also understand, this Jetson board could replace (more or less) the on-board FPGA, being more powerful(?) and easier to code for the more 'average' software engineer?. And the (high performance) (W)DSP software, that's now running on or PC's, can easily by done by that board? and not just some very basic DSP work, I see at some 'other' popular sdr transceiver. The only problem I see for now is that there will be an extra 'data highway', between the sdr hardware and the end-user interface PC, that could coarse extra problems/latency..etc.. We will see what the future brings. Thanks, 73 Bert PA2XHF Phil Harman schreef op 20-8-2014 om 13:15: > Hi Bert, > Yes, as we are today the ?new board? is connected between your SDR > hardware and your PC. > It may be possible to run both the SDR server and Client GUI software > on the one SBC or PC. Its a little early yet to know if the Jetson > board is capable of doing this. > If so, then with your SDR hardware you would have a dedicated SDR that > does not require an additional PC. This could all be packaged into a > case with a suitable touch screen etc. > You can always do that today by using a suitable SBC that will run > Windows. > 73 Phil...VK6PH > > > > ------------------------------------------------------------------------ > --- Dit e-mailbericht bevat geen virussen en malware omdat avast! Antivirus-bescherming actief is. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dc6ny at gmx.de Wed Aug 20 10:55:20 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Wed, 20 Aug 2014 19:55:20 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <000001cfbc53$85bf7be0$913e73a0$@de> Message-ID: <000001cfbc9f$e8de2bd0$ba9a8370$@de> Thanks for reply, Mark. 73, Helmut -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von Shirley M?rquez D?lcey Gesendet: Mittwoch, 20. August 2014 16:21 An: hpsdr at lists.openhpsdr.org Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** > Congratulations. Maybe a stupid question: Current bottleneck is the 1 > Gbit/s LAN connection that makes a decimation by factor 2 necessary or > limits the frequency range to 33MHz, i.e. we lose 6m band at least as > raw I/Q. Is there no (economic) way to get the LAN connection faster? > 14 and 16 Bit ADC/DACs are getting faster and low-jitter sampling > oscillators up to 300MHz are available, hence a lot of nice applications are imaginable, hi. With the current boards there may not be. But a variety of standardized higher speed interfaces are available, including eSATA, Thunderbolt, USB 3.0, and 10G Ethernet. A future design could move to one of those. _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408557320.0 From doug at dougronald.com Wed Aug 20 11:22:33 2014 From: doug at dougronald.com (Doug Ronald) Date: Wed, 20 Aug 2014 11:22:33 -0700 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <007a01cfbca3$b7bfb880$273f2980$@dougronald.com> Hi, Could you give some idea of what is the present capability with regard to FFT's per second, and the bin size? I mean extracting from the information bandwidth for communications purposes, not simply for the frequency domain display. I'm curious to know if this would allow one to FFT over a 30 MHz bandwidth to say a 500 Hz bandwidth or even a 2.4 kHz bandwidth. That would be extremely useful. Thanks, -Doug Ronald AE6SY -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Phil Harman Sent: Wednesday, August 20, 2014 12:31 AM To: hpsdr at lists.openhpsdr.org Subject: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. In order to open the SDR world to those with PC software skills we are in the process of developing a new SDR architecture. This architecture digitises the entire 0 to 30MHz radio spectrum in real time and passes the 'raw' samples directly to an associated computer. This computer then calculates the FFT of the raw samples and subsequently processes the result as the user requires. This is not a totally new concept since both the cuSDR and KISS Konsole software uses raw ADC samples to provide the wideband bandscope displays. However, for this requirement the FFT only needs to be done at the bandscope update rate of a few 10's of times per second, which hardly taxes a modern PC at all. The new concept requires that we take the FFT of all samples in real-time. This has been possible in the past - if you had access to a Cray super computer! Well now we do have access to very low cost computers that provide the processing power we need. One example of this is the new Nvidia Jetson TK1 single board computer. At a cost of $192 this board contains four ARM CPUs plus 192 CUDA processors. More details of this remarkable board can be found here: https://developer.nvidia.com/jetson-tk1 Since the CUDA cores can process data in parallel, we can use these to perform the high speed FFT. John, G0ORX, has written preliminary code for the Jetson board and has confirmed that it has the necessary performance we require. The test environment consisted of a Jetson board connected via Gigabit Ethernet to an Angelia board. A special version of FPGA code was written for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the Jetson board. We used raw Ethernet frames over the Gigabit link, in order to maximise the link bandwidth, since we require a sustained 983Mbps transfer rate. Whilst it's still early days, and there is much more to be done, this critical early success does indicate that this new architecture has a very promising future. The Jetson board is taking the role of an 'SDR Server' which I have written about in the past. In which case what benefits does this new architecture provide to openHPSR? 1. The FPGA code is greatly simplified, is easier to write and maintain, and hence uses a small percentage of the space available with a subsequent reduction in power consumption. 2. The protocol between the SDR hardware and the SDR Server is greatly simplified since the SDR hardware only has to connect to a single, dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer required. The SDR Server simply needs to know the MAC address of the SDR hardware in order to communicate. It should be possible for a single SDR hardware board to feed multiple SDR Servers, but that's something for the future. 3. Virtually all the signal processing is undertaken on the associated single board computer (SBC) or (suitable) PC. If sufficient processing power is available then the GUI can run on the same SBC. Alternatively the user's normal PC (which does not require to be high performance since it does not do any significant digital signal processing) or a Tablet, cell phone etc could be used. 4. Many more users have the necessary skills and experience to support, maintain and further develop the code. New features are added to the SDR Server code rather than the FPGA code. 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA and/or power supply restrictions may have limited adding new features. 6. Future hardware upgrades will be to the associated SBC where faster and lower cost options can be expected. Nvidia have already indicated that a 64 bit board will be available in the near future. 7. Remote access to an SDR via the Internet will enable multiple users to share the SDR with each selecting their desired frequency, bandwidth and mode. There are other potential benefits relating to simpler and lower cost SDR hardware, but that is for the future. For want of a name we are calling this new architecture 'Direct Fourier Conversion' (DFC). For those that are already experimenting with the Jetson board we do intend to release the DFC FPGA code for both Angelia and Hermes boards and I will advise when, and where, this is available. John's code is presently not available, so please don't pester him, but as soon as it reaches Beta stage it will be released. Please join me in congratulating John on this exciting development. 73 Phil....VK6PH _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408558953.0 From jm-hpsdr at themarvins.org Wed Aug 20 12:57:07 2014 From: jm-hpsdr at themarvins.org (John Marvin) Date: Wed, 20 Aug 2014 13:57:07 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F4FD93.900@themarvins.org> I see no mention of the transmit side. I assume the current prototype (FPGA in particular) is a receive only implementation? Is DUC still the planned approach for transmit? I may get my 12 receivers (simultanous WSPR reception on all current and experimental ham bands 10m and below) on Hermes yet! Thanks for the update, John AC0ZG On 8/20/2014 1:31 AM, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408564627.0 From douglas.adams at me.com Wed Aug 20 17:11:51 2014 From: douglas.adams at me.com (Doug Adams) Date: Wed, 20 Aug 2014 20:11:51 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: Phil, This all sounds great, I'm all for advancing the "state-of-the-art". It would be great if an option was to have the SBC on a PCIE bus, that way it could be placed directly into a computer with such an interface (most PC's) or put into a PCIE Expansion box (e.g. a Mac expansion box fed by a Thunderbolt cable). That would get us a very high speed connection to the device and some OS independence. Does this also mean that the proposed changes to the Metis / Hermes protocol from the "Discussion Paper - openHPSDR Ethernet Protocol" are not going to be done? 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at pharman.org Wed Aug 20 17:24:01 2014 From: phil at pharman.org (Phil Harman) Date: Thu, 21 Aug 2014 08:24:01 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F4FD93.900@themarvins.org> References: <53F4FD93.900@themarvins.org> Message-ID: <6226ab1d7b126fbb9ea9a51ba1e90654.squirrel@webmail.eftel.com.au> Hi John, Doing a similar approach for the transmitter is something for the future. If you only want 12 receivers then we can reduce it to that number :) 73 Phil... > ***** High Performance Software Defined Radio Discussion List ***** > > I see no mention of the transmit side. I assume the current prototype > (FPGA in particular) is a receive only implementation? Is DUC still the > planned approach for transmit? > > I may get my 12 receivers (simultanous WSPR reception on all current and > experimental ham bands 10m and below) on Hermes yet! > > Thanks for the update, > > John > AC0ZG > > On 8/20/2014 1:31 AM, Phil Harman wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> I'm delighted to be able to report that we have been able to develop, to >> proof-of-concept stage, a new SDR architecture. >> >> Current SDRs use the software equivalent of zero IF techniques, i.e. >> DDC, >> in order to provide (multiple) receivers. Whist this is quite >> effective, >> much of the initial DSP work is done using FPGAs, or a combination of >> FPGA >> plus dedicated DSP chips and microprocessors, rather than totally within >> the PC. >> >> As more complex features are added, the size and complexity of the FPGA >> and DSP code increases. The skills to write, debug and maintain this >> code >> is only available via a small percentage of software engineers, or >> enthusiasts, in comparison to those able to write code for PC based >> hardware. >> >> In order to open the SDR world to those with PC software skills we are >> in >> the process of developing a new SDR architecture. >> >> This architecture digitises the entire 0 to 30MHz radio spectrum in real >> time and passes the 'raw' samples directly to an associated computer. >> >> This computer then calculates the FFT of the raw samples and >> subsequently >> processes the result as the user requires. >> >> This is not a totally new concept since both the cuSDR and KISS Konsole >> software uses raw ADC samples to provide the wideband bandscope >> displays. >> >> However, for this requirement the FFT only needs to be done at the >> bandscope update rate of a few 10's of times per second, which hardly >> taxes a modern PC at all. >> >> The new concept requires that we take the FFT of all samples in >> real-time. >> >> This has been possible in the past - if you had access to a Cray super >> computer! >> >> Well now we do have access to very low cost computers that provide the >> processing power we need. One example of this is the new Nvidia Jetson >> TK1 single board computer. At a cost of $192 this board contains four >> ARM >> CPUs plus 192 CUDA processors. >> >> More details of this remarkable board can be found here: >> >> https://developer.nvidia.com/jetson-tk1 >> >> Since the CUDA cores can process data in parallel, we can use these to >> perform the high speed FFT. >> >> John, G0ORX, has written preliminary code for the Jetson board and has >> confirmed that it has the necessary performance we require. >> >> The test environment consisted of a Jetson board connected via Gigabit >> Ethernet to an Angelia board. A special version of FPGA code was >> written >> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >> the >> Jetson board. >> >> We used raw Ethernet frames over the Gigabit link, in order to maximise >> the link bandwidth, since we require a sustained 983Mbps transfer rate. >> >> Whilst it's still early days, and there is much more to be done, this >> critical early success does indicate that this new architecture has a >> very >> promising future. >> >> The Jetson board is taking the role of an 'SDR Server' which I have >> written about in the past. >> >> In which case what benefits does this new architecture provide to >> openHPSR? >> >> 1. The FPGA code is greatly simplified, is easier to write and maintain, >> and hence uses a small percentage of the space available with a >> subsequent >> reduction in power consumption. >> >> 2. The protocol between the SDR hardware and the SDR Server is greatly >> simplified since the SDR hardware only has to connect to a single, >> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >> required. The SDR Server simply needs to know the MAC address of the >> SDR >> hardware in order to communicate. It should be possible for a single >> SDR >> hardware board to feed multiple SDR Servers, but that's something for >> the >> future. >> >> 3. Virtually all the signal processing is undertaken on the associated >> single board computer (SBC) or (suitable) PC. If sufficient processing >> power is available then the GUI can run on the same SBC. Alternatively >> the >> user's normal PC (which does not require to be high performance since it >> does not do any significant digital signal processing) or a Tablet, cell >> phone etc could be used. >> >> 4. Many more users have the necessary skills and experience to support, >> maintain and further develop the code. New features are added to the SDR >> Server code rather than the FPGA code. >> >> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >> FPGA >> and/or power supply restrictions may have limited adding new features. >> >> 6. Future hardware upgrades will be to the associated SBC where faster >> and >> lower cost options can be expected. Nvidia have already indicated that >> a >> 64 bit board will be available in the near future. >> >> 7. Remote access to an SDR via the Internet will enable multiple users >> to >> share the SDR with each selecting their desired frequency, bandwidth and >> mode. >> >> There are other potential benefits relating to simpler and lower cost >> SDR >> hardware, but that is for the future. >> >> For want of a name we are calling this new architecture 'Direct Fourier >> Conversion' (DFC). >> >> For those that are already experimenting with the Jetson board we do >> intend to release the DFC FPGA code for both Angelia and Hermes boards >> and >> I will advise when, and where, this is available. >> >> John's code is presently not available, so please don't pester him, but >> as >> soon as it reaches Beta stage it will be released. >> >> Please join me in congratulating John on this exciting development. >> >> 73 Phil....VK6PH >> >> >> >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > 1408580641.0 From wb4gcs at wb4gcs.org Wed Aug 20 17:37:23 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Wed, 20 Aug 2014 20:37:23 -0400 Subject: [hpsdr] Interesting email on SDR transmit noise In-Reply-To: <5261FFA0.8080001@tx.rr.com> References: <5261FFA0.8080001@tx.rr.com> Message-ID: <53F53F43.5010205@wb4gcs.org> WOW! Has anybody made similar measurements on Penny/Munim?? 73, Jim wb4gcs at amsat.org On 10/18/2013 11:42 PM, KA5FPT Paul wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I saw the following on the Flexradio mail list. I am having some > problems understanding how a SDR transmitter can cause wide band > noise. I would have thought that with proper filtering it would be > controlled. > ----------------------------------------------------------------------------------------------- > > > Date: Wed, 16 Oct 2013 14:59:37 -0400 > From: "Gedas" > To: > Subject: [Flexradio] Noise Sidebands, Article by SM5BSZ > Message-ID: <399ADD464530473F88C1CBF0659768F5 at biggy> > Content-Type: text/plain; charset="utf-8" > > I came across this interesting article by SM5BSZ who discusses some > possible transmitter issues with many radios, including the Flex. It > has me a bit concerned. I am wondering if anyone has seen similar > data for the Flex 5000? The article may be found here: > > http://www.sm5bsz.com/dynrange/dubus313.pdf > > Gedas, W8BYA > Gallery athttp://w8bya.com > Light travels faster than sound.... > This is why some people appear bright until you hear them speak. > > -------------------------------------------------------------------------------------------------- > > > 73, > Paul Cecil > KA5FPT > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1408581443.0 From phil at pharman.org Wed Aug 20 17:53:29 2014 From: phil at pharman.org (Phil Harman) Date: Thu, 21 Aug 2014 08:53:29 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F4BEBC.9080105@home.nl> References: <53F46332.9040601@home.nl> <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> <53F4BEBC.9080105@home.nl> Message-ID: Hi Bert, > So, just to simplify, so that I also understand, this Jetson board > could replace (more or less) the on-board FPGA, > being more powerful(?) and easier to code for the more 'average' > software engineer?. Yes, it does replace a large percentage of the FPGA code, not so sure about more powerful, but many more enthusiasts will be able to contribute. If there is enough spare capacity, or a future board has, then it could also replace the PC. > And the (high performance) (W)DSP software, that's now running on or > PC's, can easily by done by that board? > and not just some very basic DSP work, I see at some 'other' popular sdr > transceiver. Yes. > The only problem I see for now is that there will be an extra 'data > highway', between the sdr hardware > and the end-user interface PC, that could coarse extra > problems/latency..etc.. The data between the SDR Server and PC will only be low bandwidth. The Audio and bandscope data can be compressed so that we are perhaps only looking at 200kbps or even less. For digital modes it may be necessary to send I&Q data to the PC which will increase the bandwidth required. > We will see what the future brings. Yes, early days for DFC yet. We still have a lot to learn! 73 Phil...VK6PH 1408582409.0 From jm-hpsdr at themarvins.org Wed Aug 20 20:35:16 2014 From: jm-hpsdr at themarvins.org (John Marvin) Date: Wed, 20 Aug 2014 21:35:16 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <6226ab1d7b126fbb9ea9a51ba1e90654.squirrel@webmail.eftel.com.au> References: <53F4FD93.900@themarvins.org> <6226ab1d7b126fbb9ea9a51ba1e90654.squirrel@webmail.eftel.com.au> Message-ID: <53F568F4.3070204@themarvins.org> Oh, I'm quite aware that with this architecture the number of receivers is purely limited by the processing power and bandwidth you can apply to the problem. I look forward to playing with a fpga supporting this for Hermes. With this architecture it might make more sense for many use cases to do the I/O on the SBC (i.e. mike/line in and headphone/speaker out), but I hope that you will also preserve the capability of using the onboard Hermes I/O, i.e. still provide a synchronous mike stream with the single ultra wide data receive stream, and a synchronous speaker headphone channel, along with the control necessary to support them. Thanks, John On 8/20/2014 6:24 PM, Phil Harman wrote: > Hi John, > > Doing a similar approach for the transmitter is something for the future. > > If you only want 12 receivers then we can reduce it to that number :) > > 73 Phil... > > > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> I see no mention of the transmit side. I assume the current prototype >> (FPGA in particular) is a receive only implementation? Is DUC still the >> planned approach for transmit? >> >> I may get my 12 receivers (simultanous WSPR reception on all current and >> experimental ham bands 10m and below) on Hermes yet! >> >> Thanks for the update, >> >> John >> AC0ZG >> >> 1408592116.0 From lstoskopf at cox.net Thu Aug 21 07:55:49 2014 From: lstoskopf at cox.net (lstoskopf at cox.net) Date: Thu, 21 Aug 2014 10:55:49 -0400 Subject: [hpsdr] HackRF tutorial Message-ID: <20140821105549.YWEKY.153771.imail@eastrmwml106> Perhaps of interest: http://greatscottgadgets.com/sdr N0UU 1408632949.0 From peroy at broadpark.no Thu Aug 21 12:05:42 2014 From: peroy at broadpark.no (=?iso-8859-1?Q?=22Per_=D8yvind_Jonsson=22?=) Date: Thu, 21 Aug 2014 21:05:42 +0200 Subject: [hpsdr] Common Hermes firmware for Anan/Alex/Apollo? Message-ID: <77c0b3bd26a74.53f65f26@broadpark.no> First, thank you to the gurus for the fantastic effort with hardware, firmware and software! There is however one Hermes issue which begs to be solved, both to reduce user confusion, and hopefully also the effort needed to update the firmware. Today we need two Hermes FW versions. My understanding is that this is because the ANAN-10 and ALEX filters have different cut-off frequencies. It would of course be nice if Hermes could auto-detect which filter board is connected, but based on the schematics I have seen this will require some hardware modifications. Possible, but not desirable. When setting up PowerSDR we already need to specify the radio model, and some of this information is sent to Hermes. Would it be possible to extend this to also send information on which filter board is used? This could allow the FW to set the proper filter parameters. According to the USB_protocol_V1.58 there does not seem to be any bits that could be used directly, but it may be possible to use some otherwise unused combinations. One possibility seems to be to use C2 in the sequence starting with C0 = 0001001x, like this: bit 7: VNA mode (no change) bit 6: Alex manual (no change) bit 5: Hermes filter board (0 = Alex or ANAN, 1 = Apollo) bit 4-3-2: If bit 5 = 1 sets Apollo options (no change) If bit 5 = 0 could be used to specify which board(s) like so: 000 - None 001 - Alex RX 010 - Alex TX 011 - Alex RX+TX 100 - ANAN-10 other combinations available for future boards? bit 1: Metis/Penelope etc Mic/Line In (no change) bit 0: Hermes etc Mic Boost (no change) Thoughts/comments? LA9WX -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at foxgulch.com Fri Aug 22 09:41:09 2014 From: larry at foxgulch.com (Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop) Date: Fri, 22 Aug 2014 10:41:09 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> Message-ID: <53F772A5.9050001@foxgulch.com> Attempted to upgrade the firmware in my 100D using HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when I attempted to write 4.1 rbf, all operations stopped. Now it won't boot. (J17 jumper on or off, doesn't help) So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and fired off the Altera Quartus Programmer v12 build 177 11/7/2012 which responded after I clicked Start as follows: Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 2014 Info (209018): Device 1 silicon ID is 0x18 Info (209044): Erasing ASP configuration device(s) Info (209024): Programming device 1 Info (209018): Device 1 silicon ID is 0x18 Info (209011): Successfully performed operation(s) Info (209061): Ended Programmer operation at Fri Aug 22 15:26:15 2014 which looked OK but no boot! Second from left front panel red led glows constantly but dim. Somewhere I noticed (post by Franz Hegener) that I should have selected EPC 128? My device (in the Quartus II 32 bit Programmer window shows Device=EPCS16 as read from Quartus-II Programmer window and also shown in the document "Quartus-II Programmer and Byteblaster" by N9VV and KCXG v2.3 dated 04/23/13. Is this my error? Any ideas to try next?? Thanks, Larry W0AY Note for record: 1. Version 12 of the Quartus II Programmer matches the "Quartus-II Programmer and Byteblaster" instructions (noted above) but the current version V12 does not. Obtain V12 here: https://www.altera.com/download/sw/dnl-sw-index.jsp# 2. Win7 refused to load the drivers provided by Altera in V14. I used the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 1408725669.0 From k5so at valornet.com Fri Aug 22 10:20:32 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Fri, 22 Aug 2014 11:20:32 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: <53F772A5.9050001@foxgulch.com> References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: Hi Larry, Sorry to hear you?re having trouble programming your 100D. I suspect that when you first had your problem you could?ve recovered by using Bootloader mode, but perhaps something went awry. No problem, it?s all recoverable no matter what you did. Sounds like you have the Quartus II Programmer and your blaster cable talking fine to each other so you needn?t worry about trying to load v14 Quartus from Altera (in fact, I recommend not using v14). Here I use Quartus II v13.0 for most of my work but the Quartus II Programmer in v12 or likely any other earlier version will work to program an EEPROM config device so I wouldn?t worry about finding a particular version of Quartus II Programmer; it?s not that critical which you use, generally (at least in my experience). The Angelia board uses an EPCS128 EEPROM configuration device (not an EPCS16) so that is the device you should specify in the Quartus II Programmer. You should be plugging your blaster cable onto P2 and loading the file ?output_file.pof? for Angelia. The ?output_file.pof? contains both the bootloader code and the binary FPGA image that gets loaded later into the FPGA. If you erroneously load ?Angelia.pof? you will not be loading the bootloader code into the EEPROM with the FPGA image, you?ll only be loading the FPGA image. It will run and come up on power up but there is not bootloader code in it so should you later wish to use ?Bootloader? mode you cannot. Use the ?output_file.pof? to load into the EEPROM and you?ll be good. 73, Joe K5SO On Aug 22, 2014, at 10:41 AM, Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Attempted to upgrade the firmware in my 100D using HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when I attempted to write 4.1 rbf, all operations stopped. Now it won't boot. (J17 jumper on or off, doesn't help) > > So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and fired off the Altera Quartus Programmer v12 build 177 11/7/2012 which responded after I clicked Start as follows: > > Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 2014 > Info (209018): Device 1 silicon ID is 0x18 > Info (209044): Erasing ASP configuration device(s) > Info (209024): Programming device 1 > Info (209018): Device 1 silicon ID is 0x18 > Info (209011): Successfully performed operation(s) > Info (209061): Ended Programmer operation at Fri Aug 22 15:26:15 2014 > > which looked OK but no boot! Second from left front panel red led glows constantly but dim. > > Somewhere I noticed (post by Franz Hegener) that I should have selected EPC 128? My device (in the Quartus II 32 bit Programmer window shows Device=EPCS16 as read from Quartus-II Programmer window and also shown in the document "Quartus-II Programmer and Byteblaster" by N9VV and KCXG v2.3 dated 04/23/13. Is this my error? > > Any ideas to try next?? > > Thanks, > Larry W0AY > > Note for record: > 1. Version 12 of the Quartus II Programmer matches the "Quartus-II Programmer and Byteblaster" instructions (noted above) but the current version V12 does not. Obtain V12 here: https://www.altera.com/download/sw/dnl-sw-index.jsp# > > 2. Win7 refused to load the drivers provided by Altera in V14. I used the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408728032.0 From k5so at valornet.com Fri Aug 22 10:34:54 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Fri, 22 Aug 2014 11:34:54 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: <6CDCF9A3-A76E-4203-8939-984BA727DED3@valornet.com> Larry, One further comment, when loading an ?output_file.pof? into your Angelia it will power up with whatever firmware version number was used when the ?output_file.pof? was created. Therefore, after recovering using the blaster cable you will still need to update the firmware version to v4.1. If v4.1 happened to be used in creating the ?output_file.pof? then you do not need to update to v4.1 as it will already be loaded as part of the ?output_file.pof?. If you?re reluctant to try the update the Angelia using the HPSDRProgrammer the I?d suggest using the HPSDR Bootloader program instead, as it seems to be more robust (using a jumper on J17 during the update operation with HPSDR Bootloader, of course). The program you?d load using the HPSDR Bootloader is the same as you?d use with the HPSDR Programmer; namely, ?Angelia_v4.1.rbf?. 73, Joe K5SO 1408728894.0 From w5wc at windstream.net Fri Aug 22 10:43:04 2014 From: w5wc at windstream.net (Doug Wigley) Date: Fri, 22 Aug 2014 12:43:04 -0500 Subject: [hpsdr] PowerSDR/OpenHPSDR mRX PS v3.2.18 released Message-ID: <005601cfbe30$877604c0$96620e40$@net> All, PowerSDR/OpenHPSDR mRX PS v3.2.18 has been released. This is primarly a maintenace release which has a few bug fixes and feature enhancements added. The noteworthy changes are: - PowerSDR will check the database version being used on startup. If the databse was written by an older version of PowerSDR you will receive a warning and a choice to reset the database at that time. - Diversity values for the Reference Source, Gain, and Phase are saved and restored by band. - Diversity can now be enabled/disabled with the Diversity Form opened. - The PTT Control port can now use the same port as the CAT Control. This release can be downloaded from the openhpsdr.org website. http://openhpsdr.org/download.php 73, Doug W5WC 1408729384.0 From jkelly at verizon.net Fri Aug 22 13:12:28 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 22 Aug 2014 16:12:28 -0400 Subject: [hpsdr] FS - Band-pass filter Message-ID: Assembled Band-pass filter (BPF for SDR HERMES, ANAN-10 or HF transceiver) Similar to: http://www.ebay.com/itm/Band-pass-filter-BPF-for-SDR-HERMES-ANAN-10-or-HF-transceiver-/251578249143? $175. shipped CONUS. Jeff K2SDR -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkelly at verizon.net Fri Aug 22 14:22:37 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 22 Aug 2014 17:22:37 -0400 Subject: [hpsdr] FS - Band-pass filter In-Reply-To: References: Message-ID: <70FA5EC3B6604DCDB8E4102C084BD771@JeffPC> SOLD. Jeff From: Jeff Kelly Sent: Friday, August 22, 2014 16:12 To: hpsdr at openhpsdr.org Subject: [hpsdr] FS - Band-pass filter ***** High Performance Software Defined Radio Discussion List ***** -------------------------------------------------------------------------------- Assembled Band-pass filter (BPF for SDR HERMES, ANAN-10 or HF transceiver) Similar to: http://www.ebay.com/itm/Band-pass-filter-BPF-for-SDR-HERMES-ANAN-10-or-HF-transceiver-/251578249143? $175. shipped CONUS. Jeff K2SDR -------------------------------------------------------------------------------- _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From leskep at skymesh.com.au Fri Aug 22 16:12:40 2014 From: leskep at skymesh.com.au (Les Keppie) Date: Sat, 23 Aug 2014 09:12:40 +1000 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: <53F772A5.9050001@foxgulch.com> References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: Hi All I have experienced a similar situation regarding v4.1 whilst trying to revert to v4.0 After upgrading to v4.1 when it became available I only had it running for a short period when I was experiencing distorted audio - checked all bands same result - decided to revert to v4.0 firmware Using Programmer old file was reported as deleted but no perecntage values appeared when uploading the new file and the process never did complete I then switched to the Bootloader and again tried load v4.0 firmware - same result as using the Programmer This happened the day before I was due to go on 2 weeks holiday so just left everything as was On returning I thought about it for a while and decided to try the Bootloader and was able to upgrade to v4.1 and no distorted audio problems - have been running it now for some 4 days without any problems Just thought I would put this out for information Regards Les VK2DSG On Sat, 23 Aug 2014 02:41:09 +1000, Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Attempted to upgrade the firmware in my 100D using > HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when > I attempted to write 4.1 rbf, all operations stopped. Now it won't > boot. (J17 jumper on or off, doesn't help) > > So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and fired > off the Altera Quartus Programmer v12 build 177 11/7/2012 which > responded after I clicked Start as follows: > > Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 2014 > Info (209018): Device 1 silicon ID is 0x18 > Info (209044): Erasing ASP configuration device(s) > Info (209024): Programming device 1 > Info (209018): Device 1 silicon ID is 0x18 > Info (209011): Successfully performed operation(s) > Info (209061): Ended Programmer operation at Fri Aug 22 15:26:15 2014 > > which looked OK but no boot! Second from left front panel red led > glows constantly but dim. > > Somewhere I noticed (post by Franz Hegener) that I should have > selected EPC 128? My device (in the Quartus II 32 bit Programmer > window shows Device=EPCS16 as read from Quartus-II Programmer window and > also shown in the document "Quartus-II Programmer and Byteblaster" by > N9VV and KCXG v2.3 dated 04/23/13. Is this my error? > > Any ideas to try next?? > > Thanks, > Larry W0AY > > Note for record: > 1. Version 12 of the Quartus II Programmer matches the "Quartus-II > Programmer and Byteblaster" instructions (noted above) but the current > version V12 does not. Obtain V12 here: > https://www.altera.com/download/sw/dnl-sw-index.jsp# > > 2. Win7 refused to load the drivers provided by Altera in V14. I used > the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Using Opera's mail client: http://www.opera.com/mail/ 1408749160.0 From k5so at valornet.com Fri Aug 22 18:07:18 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Fri, 22 Aug 2014 19:07:18 -0600 Subject: [hpsdr] Angelia_v4.2 firmware release Message-ID: All, Angelia_v4.2 firmware is available for download from http://k5so.com/HPSDR_downloads.html This version of firmware slightly modifies the timing of v4.1 to make the design more robust with respect to running on many different Angelia boards. A few people have reported problems with v4.1 where one or more features became inoperable after 30 minutes or so of operation (e.g., CW sidetone simply stopping, etc). Most Angelia boards had no problem with v4.1 apparently but a few did. This v4.2 appears to have fixed those problems and appears to work fine on other Angelia boards too. I don?t know if the recently reported trouble experienced by a few people using HPSDR Programmer to update firmware in Angelia will be helped by this new firmware but it could, perhaps. In any case, should you run into trouble using HPSDR Programmer in the normal manner you should be able to use the HPSDR Bootloader program to recover. For those who wish to use the "brute force" method of completely reloading the Angelia EEPROM (including the bootloader code) by using a blaster cable with the Quartus II Programmer, I have created a new ?output_file.pof? file that includes both Angelia_v4.2 image and the bootloader code in it and I have included it in the zipped Angelia_v4.2 download folder. Using this ?output_file.pof? file will relieve you of the task of updating to v4.2 after loading the bootloader code, which you would need to do if you use an earlier version of ?output_file.pof? in your blaster cable process. Please keep in mind that you should not need to use a blaster cable to recover from a failed attempt to update firmware using HPSDR Programmer; recovery using HPSDR Bootloader (with J17 jumper in place, of course) should work for you in those (hopefully relatively rare!) cases. I included this new ?output_file.pof" file in the download folder only as a ?peace of mind? item and courtesy for those who like to use their blaster cables, hihi. 73, Joe K5SO 1408756038.0 From mlalonde at alphatronique.com Fri Aug 22 19:31:43 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Fri, 22 Aug 2014 22:31:43 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F7FD0F.6020301@alphatronique.com> Hi guess some one already work on a ADC /DAC Board that go on the expansion connector of the DEV kit ? seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA as Glue logic.. that may remove the LAN / PHY from equation and permit made nice self contained platform ;-) if no one yet ,i may willing to help work on this ,i was a senior PCB designer whit some design backgrond .. Best 73! Marc VE2OLM On 20/08/2014 3:31 AM, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1408761103.0 From aa8k73 at gmail.com Fri Aug 22 19:43:52 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 22 Aug 2014 22:43:52 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/23 Message-ID: <53F7FFE8.3030108@gmail.com> The 23/Aug TeamSpeak mp3 (63 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3512 > or < http://www.hamsdr.com/dnld.aspx > Only silence truncation editing was done on this recording. Session text follows <20:35:08> *** You are now talking in channel: "OpenHPSDR" <21:06:29> "Bill - KD5TFD": needs better networking? <21:08:21> "Bill - KD5TFD": If he's an expert it's only an afternoon project <21:13:48> "Ken N9VV": CWSkimmer <21:18:15> "Warren - NR0V": < https://dl.dropboxusercontent.com/u/9282924/hpsdr/xcmaster.JPG > <21:28:04> "Ken N9VV": "Bonding" <21:28:32> "Bill - KD5TFD": 2 lane highway <21:28:56> "Jae - K5JAE": pci-e? <21:31:32> "Bill - KD5TFD": You mean I can't do 30 Mhz wide transmit? <21:32:20> "Bill - KD5TFD": light weight gui .. now that's an oxymoron <21:33:26> "Ken N9VV": Lightweight GUI = Android glSDR or HPSDR with Qt server doing all the work(?) <21:36:02> "Jae - K5JAE": FreeDV? <21:46:03> "Ken N9VV": K5SO released Angelia 4.2 tonight --- < http://k5so.com/Angelia_v4.2.zip > <21:47:46> "Bill - KD5TFD": anyone have a vnc server running on their Jetson? <21:51:50> "Jae - K5JAE": software is soft... hardware is hard :) <21:52:45> "Ken N9VV": SDRMAX = circa: 2004 according to N8VB Blog <21:55:56> "Rob - VE3EW": < http://www.iwavesystems.com/product/cpu-modules/cyclone-v-soc-qseven-som/altera-cyclone-v-soc-qseven-module.html > <21:57:12> "Bill - KD5TFD": awful lot of expertise in building a full blown computer board <21:57:43> "Bill - KD5TFD": an dcan you get it debugged in our lifetimes ... <22:05:12> "Bill - KD5TFD": dwim <22:05:27> "Bill - KD5TFD": dwim eax, edx <22:05:30> "Jae - K5JAE": is that called c#? 1408761832.0 From phil at pharman.org Fri Aug 22 20:31:13 2014 From: phil at pharman.org (Phil Harman) Date: Sat, 23 Aug 2014 11:31:13 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F7FD0F.6020301@alphatronique.com> References: <53F7FD0F.6020301@alphatronique.com> Message-ID: <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Hi Marc, Thanks for your email. We still have a way to go with fully proving the DFC idea but so far its looking good. We actually had this discussion a few minutes ago during the weekly Teamspeak session. Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. If such a PCB design is of interest to you then please lets discuss further. 73 Phil....VK6PH -----Original Message----- From: Marc Lalonde Sent: Saturday, August 23, 2014 10:31 AM To: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Hi guess some one already work on a ADC /DAC Board that go on the expansion connector of the DEV kit ? seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA as Glue logic.. that may remove the LAN / PHY from equation and permit made nice self contained platform ;-) if no one yet ,i may willing to help work on this ,i was a senior PCB designer whit some design backgrond .. Best 73! Marc VE2OLM On 20/08/2014 3:31 AM, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to > openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1408764673.0 From rick at teksharp.com Sat Aug 23 06:20:21 2014 From: rick at teksharp.com (Rick Fletcher) Date: Sat, 23 Aug 2014 07:20:21 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: <00ef01cfbed5$0b5c8d00$2215a700$@teksharp.com> I'm still running V3.5 and have experienced distorted audio twice. Both times, I was able to restore normal operation by terminating PowerSDR and launching a new instance of it. 73, Rick, W7YP -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Les Keppie Sent: Friday, August 22, 2014 5:13 PM To: larry at foxgulch.com; hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable ***** High Performance Software Defined Radio Discussion List ***** Hi All I have experienced a similar situation regarding v4.1 whilst trying to revert to v4.0 After upgrading to v4.1 when it became available I only had it running for a short period when I was experiencing distorted audio - checked all bands same result - decided to revert to v4.0 firmware Using Programmer old file was reported as deleted but no perecntage values appeared when uploading the new file and the process never did complete I then switched to the Bootloader and again tried load v4.0 firmware - same result as using the Programmer This happened the day before I was due to go on 2 weeks holiday so just left everything as was On returning I thought about it for a while and decided to try the Bootloader and was able to upgrade to v4.1 and no distorted audio problems - have been running it now for some 4 days without any problems Just thought I would put this out for information Regards Les VK2DSG On Sat, 23 Aug 2014 02:41:09 +1000, Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Attempted to upgrade the firmware in my 100D using > HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when > I attempted to write 4.1 rbf, all operations stopped. Now it won't > boot. (J17 jumper on or off, doesn't help) > > So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and > fired off the Altera Quartus Programmer v12 build 177 11/7/2012 which > responded after I clicked Start as follows: > > Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 > 2014 Info (209018): Device 1 silicon ID is 0x18 Info (209044): Erasing > ASP configuration device(s) Info (209024): Programming device 1 Info > (209018): Device 1 silicon ID is 0x18 Info (209011): Successfully > performed operation(s) Info (209061): Ended Programmer operation at > Fri Aug 22 15:26:15 2014 > > which looked OK but no boot! Second from left front panel red led > glows constantly but dim. > > Somewhere I noticed (post by Franz Hegener) that I should have > selected EPC 128? My device (in the Quartus II 32 bit Programmer > window shows Device=EPCS16 as read from Quartus-II Programmer window > and also shown in the document "Quartus-II Programmer and Byteblaster" by > N9VV and KCXG v2.3 dated 04/23/13. Is this my error? > > Any ideas to try next?? > > Thanks, > Larry W0AY > > Note for record: > 1. Version 12 of the Quartus II Programmer matches the "Quartus-II > Programmer and Byteblaster" instructions (noted above) but the current > version V12 does not. Obtain V12 here: > https://www.altera.com/download/sw/dnl-sw-index.jsp# > > 2. Win7 refused to load the drivers provided by Altera in V14. I used > the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Using Opera's mail client: http://www.opera.com/mail/ _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408800021.0 From mlalonde at alphatronique.com Sat Aug 23 06:42:14 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Sat, 23 Aug 2014 09:42:14 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <53F89A36.4070905@alphatronique.com> Hi Phil, After some quick reading it seems that ePCI bus is Point to Point (no need for southBridge) It may sure be a good idea and let option to upgrade the Nvidia card later as tech advance. My work schedule have a bit more room on September so if there is need I will be happy to jump in. Best 73! On 22/08/2014 11:31 PM, Phil Harman wrote: > Hi Marc, > > Thanks for your email. > > We still have a way to go with fully proving the DFC idea but so far > its looking good. > > We actually had this discussion a few minutes ago during the weekly > Teamspeak session. > > Whilst the GPIO is one solution our concern is that the Jetson board > is not going to be a production item for Nvidia. There is no > guarantee that what board replaces it, be it 64 bit Jeston or > something completely different, may not have the same GIPO port. > > What does look viable is a board using miniPCIe since there is a > good possibility that future SBCs will carry this interface. > > What was suggested was a miniPCIe board with an Altera Cyclone V FPGA > (since this has PCIe implement in hardware on the chip) plus an ADC, > DAC and I/O. The I/O could include an interface to the Alex board so > we can use that rather than reproduce that hardware. > > With an FPGA on the board we have many options from DFC down to > porting the existing DDC/DUC code, which is all ready proven to work. > > If such a PCB design is of interest to you then please lets discuss > further. > > 73 Phil....VK6PH > > > > > -----Original Message----- From: Marc Lalonde > Sent: Saturday, August 23, 2014 10:31 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > guess some one already work on a ADC /DAC Board that go on the expansion > connector of the DEV kit ? > seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA > as Glue logic.. > > that may remove the LAN / PHY from equation and permit made nice self > contained platform ;-) > > if no one yet ,i may willing to help work on this ,i was a senior PCB > designer whit some design backgrond .. > > Best 73! > Marc VE2OLM > > On 20/08/2014 3:31 AM, Phil Harman wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> I'm delighted to be able to report that we have been able to develop, to >> proof-of-concept stage, a new SDR architecture. >> >> Current SDRs use the software equivalent of zero IF techniques, i.e. >> DDC, >> in order to provide (multiple) receivers. Whist this is quite >> effective, >> much of the initial DSP work is done using FPGAs, or a combination of >> FPGA >> plus dedicated DSP chips and microprocessors, rather than totally within >> the PC. >> >> As more complex features are added, the size and complexity of the FPGA >> and DSP code increases. The skills to write, debug and maintain this >> code >> is only available via a small percentage of software engineers, or >> enthusiasts, in comparison to those able to write code for PC based >> hardware. >> >> In order to open the SDR world to those with PC software skills we >> are in >> the process of developing a new SDR architecture. >> >> This architecture digitises the entire 0 to 30MHz radio spectrum in real >> time and passes the 'raw' samples directly to an associated computer. >> >> This computer then calculates the FFT of the raw samples and >> subsequently >> processes the result as the user requires. >> >> This is not a totally new concept since both the cuSDR and KISS Konsole >> software uses raw ADC samples to provide the wideband bandscope >> displays. >> >> However, for this requirement the FFT only needs to be done at the >> bandscope update rate of a few 10's of times per second, which hardly >> taxes a modern PC at all. >> >> The new concept requires that we take the FFT of all samples in >> real-time. >> >> This has been possible in the past - if you had access to a Cray super >> computer! >> >> Well now we do have access to very low cost computers that provide the >> processing power we need. One example of this is the new Nvidia Jetson >> TK1 single board computer. At a cost of $192 this board contains >> four ARM >> CPUs plus 192 CUDA processors. >> >> More details of this remarkable board can be found here: >> >> https://developer.nvidia.com/jetson-tk1 >> >> Since the CUDA cores can process data in parallel, we can use these to >> perform the high speed FFT. >> >> John, G0ORX, has written preliminary code for the Jetson board and has >> confirmed that it has the necessary performance we require. >> >> The test environment consisted of a Jetson board connected via Gigabit >> Ethernet to an Angelia board. A special version of FPGA code was >> written >> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps >> to the >> Jetson board. >> >> We used raw Ethernet frames over the Gigabit link, in order to maximise >> the link bandwidth, since we require a sustained 983Mbps transfer rate. >> >> Whilst it's still early days, and there is much more to be done, this >> critical early success does indicate that this new architecture has a >> very >> promising future. >> >> The Jetson board is taking the role of an 'SDR Server' which I have >> written about in the past. >> >> In which case what benefits does this new architecture provide to >> openHPSR? >> >> 1. The FPGA code is greatly simplified, is easier to write and maintain, >> and hence uses a small percentage of the space available with a >> subsequent >> reduction in power consumption. >> >> 2. The protocol between the SDR hardware and the SDR Server is greatly >> simplified since the SDR hardware only has to connect to a single, >> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >> required. The SDR Server simply needs to know the MAC address of the >> SDR >> hardware in order to communicate. It should be possible for a single >> SDR >> hardware board to feed multiple SDR Servers, but that's something for >> the >> future. >> >> 3. Virtually all the signal processing is undertaken on the associated >> single board computer (SBC) or (suitable) PC. If sufficient processing >> power is available then the GUI can run on the same SBC. >> Alternatively the >> user's normal PC (which does not require to be high performance since it >> does not do any significant digital signal processing) or a Tablet, cell >> phone etc could be used. >> >> 4. Many more users have the necessary skills and experience to support, >> maintain and further develop the code. New features are added to the SDR >> Server code rather than the FPGA code. >> >> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >> FPGA >> and/or power supply restrictions may have limited adding new features. >> >> 6. Future hardware upgrades will be to the associated SBC where >> faster and >> lower cost options can be expected. Nvidia have already indicated >> that a >> 64 bit board will be available in the near future. >> >> 7. Remote access to an SDR via the Internet will enable multiple >> users to >> share the SDR with each selecting their desired frequency, bandwidth and >> mode. >> >> There are other potential benefits relating to simpler and lower cost >> SDR >> hardware, but that is for the future. >> >> For want of a name we are calling this new architecture 'Direct Fourier >> Conversion' (DFC). >> >> For those that are already experimenting with the Jetson board we do >> intend to release the DFC FPGA code for both Angelia and Hermes >> boards and >> I will advise when, and where, this is available. >> >> John's code is presently not available, so please don't pester him, >> but as >> soon as it reaches Beta stage it will be released. >> >> Please join me in congratulating John on this exciting development. >> >> 73 Phil....VK6PH >> >> >> >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > 1408801334.0 From sbdick at optonline.net Sat Aug 23 08:13:24 2014 From: sbdick at optonline.net (Steven B. Dick) Date: Sat, 23 Aug 2014 11:13:24 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: Phil, as you indicated, The skills to write, debug and maintain FPGA code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. This has been a major problem in industry for years, as the cost per "line of code" is much higher for firmware vs. software for code development and maintenance, on the order of a factor of perhaps 10 to 1 for FPGA firmware vs. software written in a high order language. Note that tools such as MATLAB can be used to develop FPGA code directly rather than hand coding verilog or VHDL code but are not low cost tools. Another approach to consider is the newly emerging FPGA vendor support of high order "graphics" programming languages for their latest "System on a chip" FPGAs. Both Altera and Xilinx are now beginning to support the OpenCL programming language for their FPGAs using their latest toolsets. OpenCL is not proprietary vs. CUDA which is tied in with NVIDIA. CUDA is more mature and has a more extensive set of available libraries and a larger user community however. Although programming with OpenCL on an FPGA vs. a graphics chip using multiple graphics processing engines requires different programming approaches to take best advantages of the underlying hardware resources, this may be a way to program for "System on a chip" FPGAs, strictly in software though maintining a mix of hardware and software resources, including multiple ARM processors. Regards. "Digital Steve", K1RF -----Original Message----- All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. *********************** 1408806804.0 From rcrewson at cinci.rr.com Sat Aug 23 09:26:41 2014 From: rcrewson at cinci.rr.com (Rob Crewson) Date: Sat, 23 Aug 2014 12:26:41 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> Hi Steve, I have been looking OpenCL for a couple of months by taking some online courses. Of note is that NVidia also belongs and supports the consortium. Unfortunately in the last one of the series (just watched it today ), it mentions that a fully licensed of QuartusII is needed in order to actually get compiled code generated and loaded on a FPGA. I did not check the development board costs at that point but they are licensed for a fee as well. 73, Rob Crewson - VE3EW -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Steven B. Dick Sent: Saturday, August 23, 2014 11:13 AM To: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Phil, as you indicated, The skills to write, debug and maintain FPGA code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. This has been a major problem in industry for years, as the cost per "line of code" is much higher for firmware vs. software for code development and maintenance, on the order of a factor of perhaps 10 to 1 for FPGA firmware vs. software written in a high order language. Note that tools such as MATLAB can be used to develop FPGA code directly rather than hand coding verilog or VHDL code but are not low cost tools. Another approach to consider is the newly emerging FPGA vendor support of high order "graphics" programming languages for their latest "System on a chip" FPGAs. Both Altera and Xilinx are now beginning to support the OpenCL programming language for their FPGAs using their latest toolsets. OpenCL is not proprietary vs. CUDA which is tied in with NVIDIA. CUDA is more mature and has a more extensive set of available libraries and a larger user community however. Although programming with OpenCL on an FPGA vs. a graphics chip using multiple graphics processing engines requires different programming approaches to take best advantages of the underlying hardware resources, this may be a way to program for "System on a chip" FPGAs, strictly in software though maintining a mix of hardware and software resources, including multiple ARM processors. Regards. "Digital Steve", K1RF -----Original Message----- All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. *********************** _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408811201.0 From k5so at valornet.com Sat Aug 23 11:06:14 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sat, 23 Aug 2014 12:06:14 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> Message-ID: <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> A personal comment regarding FPGA programming and programming in general: The view that writing and maintaining FPGA code is beyond the capability of most of us has been blown completely out of proportion to reality! That view is simply incorrect. Indeed, I?m a good example of the point, I think. As many of you know, I am certainly not a professional programmer and, in fact, I have had no serious programming experience at all in any computer language in my life. Since joining the HPSDR community a few years ago I have managed to muddle my way along in learning how to successfully write both FPGA code and PowerSDR (C# and C) code and have discovered that it simply isn?t that hard to do. I readily admit that my code isn?t ?elegant? in the purist view but it works (sometimes anyway, hihi). The point I?m trying to make is that you only have to be willing to learn something new, that?s all, and not be too timid to give it a try to ultimately become successful in doing ANY of the programming we do. Indeed, it turns out that even the often-viewed-as-no-man?s-land of timing FPGA designs is actually completely accessible to non-professionals such as we are and, in fact, the task is easily within the grasp of the average experimenter. Further, we have always used and are still using free versions of Quartus II to create FPGA designs and load the FPGAs without problem. You don?t have to have the fully licensed Quartus II versions to do anything we wish to do with these FPGAs. Counter to what one might assume from the recent discussions, any of us can do FPGA programming with the free tools we have available from Altera if you only care to put the effort into learning how to do it. It just isn?t that hard! I?m certainly no expert in any of this stuff and would never claim to be but you don?t have to be an expert to be able to learn to work with these tools and be able to make meaningful contributions. There is no reason at all that only a small percentage of our group can do FPGA programming! The truth is that anyone can do it if you set your mind to do it. 73, Joe K5SO On Aug 23, 2014, at 10:26 AM, Rob Crewson wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Steve, > > I have been looking OpenCL for a couple of months by taking some online > courses. > Of note is that NVidia also belongs and supports the consortium. > > Unfortunately in the last one of the series (just watched it today ), it > mentions that a fully licensed of QuartusII > is needed in order to actually get compiled code generated and loaded on > a FPGA. > > I did not check the development board costs at that point but they are > licensed for a fee as well. > > 73, > > Rob Crewson - VE3EW > > > > -----Original Message----- > From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Steven > B. Dick > Sent: Saturday, August 23, 2014 11:13 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > ***** High Performance Software Defined Radio Discussion List ***** > > Phil, as you indicated, The skills to write, debug and maintain FPGA code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. This has been a major problem in industry for years, as the cost > per "line of code" is much higher for firmware vs. software for code > development and maintenance, on the order of a factor of perhaps 10 to 1 for > FPGA firmware vs. software written in a high order language. Note that > tools such as MATLAB can be used to develop FPGA code directly rather than > hand coding verilog or VHDL code but are not low cost tools. > > Another approach to consider is the newly emerging FPGA vendor support of > high order "graphics" programming languages for their latest "System on a > chip" FPGAs. Both Altera and Xilinx are now beginning to support the OpenCL > programming language for their FPGAs using their latest toolsets. OpenCL is > not proprietary vs. CUDA which is tied in with NVIDIA. CUDA is more mature > and has a more extensive set of available libraries and a larger user > community however. Although programming with OpenCL on an FPGA vs. a > graphics chip using multiple graphics processing engines requires different > programming approaches to take best advantages of the underlying hardware > resources, this may be a way to program for "System on a chip" FPGAs, > strictly in software though maintining a mix of hardware and software > resources, including multiple ARM processors. > > Regards. "Digital Steve", K1RF > > -----Original Message----- > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within the > PC. > > As more complex features are added, the size and complexity of the FPGA and > DSP code increases. The skills to write, debug and maintain this code is > only available via a small percentage of software engineers, or enthusiasts, > in comparison to those able to write code for PC based hardware. > > *********************** > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408817174.0 From sbdick at optonline.net Sat Aug 23 12:10:10 2014 From: sbdick at optonline.net (Steven B. Dick) Date: Sat, 23 Aug 2014 15:10:10 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> Message-ID: <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with a desire to learn and my hat is off to you for taking it upon yourself to learn both firmware and software programming. That was not the point I was trying to make. In my previous life, I was a digital design manager. FPGA code designed by experienced senior FPGA designers took a lot more time to develop (even worse to maintain) compared to software written by experienced software developers which ran on general purpose compute nodes. For many years, FPGA designs had an important role to play where special functions just could not be done in general purpose processors or even DSP processors with comparable performance, but one willingly paid for it in reaping the benefits of high performance and/or greatly reduced hardware footprint. But the processing landscape is changing nowadays with very low cost processing platforms based on multiple node graphics engines coupled with high order language support with DSP libraries. Use of these platforms is starting to result in huge performance capabilities in a low cost rapid development environment if these platforms can be readily used for particular applications including the FFT function. Regards, "Digital Steve", K1RF -----Original Message----- From: Joe Martin K5SO [mailto:k5so at valornet.com] Sent: Saturday, August 23, 2014 2:06 PM To: Rob Crewson Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development A personal comment regarding FPGA programming and programming in general: The view that writing and maintaining FPGA code is beyond the capability of most of us has been blown completely out of proportion to reality! That view is simply incorrect. Indeed, I'm a good example of the point, I think. 1408821010.0 From k5so at valornet.com Sat Aug 23 12:23:43 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sat, 23 Aug 2014 13:23:43 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> Message-ID: <260DD696-CE58-4F14-A24E-55B5FFCCDC3F@valornet.com> There are many such sources for information. To learn the basics of the Verilog language, which is what we use to write the FPGA code designs, Kirk Weedman KD7IRS some years ago kindly put together a beginners course tailored to the HPSDR project. The course is available for download on the HPSDR webpage below: http://verilog.openhpsdr.org However, in my experience the absolute best way to learn how to do this is by downloading Quartus II, installing it on your computer, and using it to examine an existing HPSDR firmware design. By examing an actual firmware design that we are using today you can see how the various tasks are accomplished in the code. We try to comment the code as much as is practical in order to help us remember what each section does but also to help newcomers understand what the code section is doing. You can spend lots of unnecessary time attending/viewing classes which will be giving you much info regarding Verilog syntax, etc, but you can also get the idea very quickly by examining an actual firmware design by using the Quartus II editor. In addition, you?ll immediately be learning how to use the Quartus II tool. In short, my view that the absolute best way to learn is to get your feet wet immediately with the tool that you will be using; i.e., Quartus II, to examine an existing firmware design. The primary issue to understand about FPGA code, in my view, is to realize from the start that each little section of code within the firmware design runs in parallel with every other section. That is, the code execution is not ?event driven? as it is in Windows programming nor is it strictly running lines of code sequentially as in some languages (except within each section of code in the firmare design). Because of this it is actually easy to take one little section of code and examine it carefully to see what it is doing, how it is doing it, and what syntax is used to accomplish it. After you feel you understand a portion of it then you can make small changes to it, compile it, and see what effect your change(s) have on the performance of the firmware design by actually loading it into your HPSDR rigs? FPGA. Plus you immediately gain experience in how to do all that. Sure, you?ll make mistakes! But be assured that anything you do is recoverable; you can?t hurt the FPGA by misprogramming it. 73, Joe K5SO On Aug 23, 2014, at 12:46 PM, Neal Campbell wrote: > Are there any good beginner courses on the internet? > > 73 > > Neal Campbell > Abroham Neal LLC > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Sat Aug 23 12:46:38 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sat, 23 Aug 2014 13:46:38 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> Message-ID: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> Hi Steve, RR, understood. I appreciate your point. But as you noted, the landscape has changed and is continually changing such that the world of FPGA programming is not limited to those senior FPGA programmers anymore. Granted, who knows if or how long FPGAs will be important, but for our project right now and for the forseeable future they are central to our designs. Therefore, it should be understood by all that the domain of FPGA programming is certainly not now limited to ?senior FPGA programmers?. We can successfully do such programming ourselves if we want to do it. 73, Joe K5SO On Aug 23, 2014, at 1:10 PM, Steven B. Dick wrote: > Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with > a desire to learn and my hat is off to you for taking it upon yourself to > learn both firmware and software programming. That was not the point I was > trying to make. In my previous life, I was a digital design manager. FPGA > code designed by experienced senior FPGA designers took a lot more time to > develop (even worse to maintain) compared to software written by experienced > software developers which ran on general purpose compute nodes. For many > years, FPGA designs had an important role to play where special functions > just could not be done in general purpose processors or even DSP processors > with comparable performance, but one willingly paid for it in reaping the > benefits of high performance and/or greatly reduced hardware footprint. But > the processing landscape is changing nowadays with very low cost processing > platforms based on multiple node graphics engines coupled with high order > language support with DSP libraries. Use of these platforms is starting to > result in huge performance capabilities in a low cost rapid development > environment if these platforms can be readily used for particular > applications including the FFT function. > > Regards, > "Digital Steve", K1RF > > -----Original Message----- > From: Joe Martin K5SO [mailto:k5so at valornet.com] > Sent: Saturday, August 23, 2014 2:06 PM > To: Rob Crewson > Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > A personal comment regarding FPGA programming and programming in general: > > The view that writing and maintaining FPGA code is beyond the capability of > most of us has been blown completely out of proportion to reality! That > view is simply incorrect. > > Indeed, I'm a good example of the point, I think. > 1408823198.0 From n9vv at wowway.com Sat Aug 23 16:13:32 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Sat, 23 Aug 2014 18:13:32 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> Message-ID: <53F9201C.8050306@wowway.com> P.S. I think Joe has a 4 digit IQ and he is just too polite to tell us!! 73 de Ken N9VV On 8/23/2014 2:46 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Steve, > > RR, understood. I appreciate your point. > > But as you noted, the landscape has changed and is continually changing such that the world of FPGA programming is not limited to those senior FPGA programmers anymore. Granted, who knows if or how long FPGAs will be important, but for our project right now and for the forseeable future they are central to our designs. Therefore, it should be understood by all that the domain of FPGA programming is certainly not now limited to ?senior FPGA programmers?. We can successfully do such programming ourselves if we want to do it. > > 73, Joe K5SO > > On Aug 23, 2014, at 1:10 PM, Steven B. Dick wrote: > >> Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with >> a desire to learn and my hat is off to you for taking it upon yourself to >> learn both firmware and software programming. That was not the point I was >> trying to make. In my previous life, I was a digital design manager. FPGA >> code designed by experienced senior FPGA designers took a lot more time to >> develop (even worse to maintain) compared to software written by experienced >> software developers which ran on general purpose compute nodes. For many >> years, FPGA designs had an important role to play where special functions >> just could not be done in general purpose processors or even DSP processors >> with comparable performance, but one willingly paid for it in reaping the >> benefits of high performance and/or greatly reduced hardware footprint. But >> the processing landscape is changing nowadays with very low cost processing >> platforms based on multiple node graphics engines coupled with high order >> language support with DSP libraries. Use of these platforms is starting to >> result in huge performance capabilities in a low cost rapid development >> environment if these platforms can be readily used for particular >> applications including the FFT function. >> >> Regards, >> "Digital Steve", K1RF >> >> -----Original Message----- >> From: Joe Martin K5SO [mailto:k5so at valornet.com] >> Sent: Saturday, August 23, 2014 2:06 PM >> To: Rob Crewson >> Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org >> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >> >> A personal comment regarding FPGA programming and programming in general: >> >> The view that writing and maintaining FPGA code is beyond the capability of >> most of us has been blown completely out of proportion to reality! That >> view is simply incorrect. >> >> Indeed, I'm a good example of the point, I think. >> > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1408835612.0 From w4yn at earthlink.net Sat Aug 23 16:18:39 2014 From: w4yn at earthlink.net (Tim ORourke) Date: Sat, 23 Aug 2014 19:18:39 -0400 (GMT-04:00) Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <11504088.1408835920124.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> I think all the guys doing this are 4 digit geeks! And that's a great attribute IMHO! Tim Tim O\Rourke W4YN at ARRL.Net Low Power Amateur Radio Rocks Member of Flying Pigs,ARCI,GQRP,RSGB,ARRL Life Member R/C Pilot (sort of) NRA Life Member NRA Certified Rifle, Pistol, Black Powder Instructor, Range Officer -----Original Message----- >From: "Ken N9VV (Win-7/64)" >Sent: Aug 23, 2014 7:13 PM >To: hpsdr at lists.openhpsdr.org >Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > >***** High Performance Software Defined Radio Discussion List ***** > >P.S. I think Joe has a 4 digit IQ and he is just too polite to tell us!! > >73 de Ken N9VV > >On 8/23/2014 2:46 PM, Joe Martin K5SO wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Steve, >> >> RR, understood. I appreciate your point. >> >> But as you noted, the landscape has changed and is continually changing such that the world of FPGA programming is not limited to those senior FPGA programmers anymore. Granted, who knows if or how long FPGAs will be important, but for our project right now and for the forseeable future they are central to our designs. Therefore, it should be understood by all that the domain of FPGA programming is certainly not now limited to ?senior FPGA programmers?. We can successfully do such programming ourselves if we want to do it. >> >> 73, Joe K5SO >> >> On Aug 23, 2014, at 1:10 PM, Steven B. Dick wrote: >> >>> Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with >>> a desire to learn and my hat is off to you for taking it upon yourself to >>> learn both firmware and software programming. That was not the point I was >>> trying to make. In my previous life, I was a digital design manager. FPGA >>> code designed by experienced senior FPGA designers took a lot more time to >>> develop (even worse to maintain) compared to software written by experienced >>> software developers which ran on general purpose compute nodes. For many >>> years, FPGA designs had an important role to play where special functions >>> just could not be done in general purpose processors or even DSP processors >>> with comparable performance, but one willingly paid for it in reaping the >>> benefits of high performance and/or greatly reduced hardware footprint. But >>> the processing landscape is changing nowadays with very low cost processing >>> platforms based on multiple node graphics engines coupled with high order >>> language support with DSP libraries. Use of these platforms is starting to >>> result in huge performance capabilities in a low cost rapid development >>> environment if these platforms can be readily used for particular >>> applications including the FFT function. >>> >>> Regards, >>> "Digital Steve", K1RF >>> >>> -----Original Message----- >>> From: Joe Martin K5SO [mailto:k5so at valornet.com] >>> Sent: Saturday, August 23, 2014 2:06 PM >>> To: Rob Crewson >>> Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org >>> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >>> >>> A personal comment regarding FPGA programming and programming in general: >>> >>> The view that writing and maintaining FPGA code is beyond the capability of >>> most of us has been blown completely out of proportion to reality! That >>> view is simply incorrect. >>> >>> Indeed, I'm a good example of the point, I think. >>> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >_______________________________________________ >HPSDR Discussion List >To post msg: hpsdr at openhpsdr.org >Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >HPSDR web page: http://openhpsdr.org >Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408835919.0 From scotty at tonks.com Sat Aug 23 16:43:31 2014 From: scotty at tonks.com (Scott Cowling) Date: Sat, 23 Aug 2014 16:43:31 -0700 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <260DD696-CE58-4F14-A24E-55B5FFCCDC3F@valornet.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> <260DD696-CE58-4F14-A24E-55B5FFCCDC3F@valornet.com> Message-ID: <53F92723.8020105@tonks.com> I want to echo Joe's sentiments on FPGA development exactly. In many respects, getting started in FPGA programming is *easier* than jumping into C++ programming. When you download the tools, the environment is all set up for you. You do not need to try to figure out which toolset to use, where to get it, how to configure it, etc. There are many excellent references and tutorials available for learning Verilog. If you are already a hardware designer, it is even easier, since Verilog synthesis constructs generate hardware. You can start out with the simple constructs, then learn and use more "elegant" style as you go. The absolute best way to start is by reading, understanding and modifying existing code examples. The SDRstick BeRadio FPGA design is a good starting place. Look in svn.sdrstick.com under "sdrstick-release/beradio/beradio-firmware/source". This is a commented, stand-alone AM radio design in Verilog. You can even get hardware to run it on if you like, but it is not necessary; there is benefit to gain just by studying the sample code. There are small FPGA development kits for as little as $49 if you want to try your hand at writing a "Hello LED" program (the hardware equivalent of the beginning C programmer's "Hello World" program). The two main things to remember are: 1. don't be afraid to jump right in 2. take it slowly and *have fun* I have been programming FPGAs since the 1980s, and it is *still* fun! 73, Scotty WA2DFI On 2014-08-23 12:23, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > There are many such sources for information. To learn the basics of the > Verilog language, which is what we use to write the FPGA code designs, > Kirk Weedman KD7IRS some years ago kindly put together a beginners > course tailored to the HPSDR project. The course is available for > download on the HPSDR webpage below: > > http://verilog.openhpsdr.org > > However, in my experience the absolute best way to learn how to do this > is by downloading Quartus II, installing it on your computer, and using > it to examine an existing HPSDR firmware design. By examing an actual > firmware design that we are using today you can see how the various > tasks are accomplished in the code. We try to comment the code as much > as is practical in order to help us remember what each section does but > also to help newcomers understand what the code section is doing. > > You can spend lots of unnecessary time attending/viewing classes which > will be giving you much info regarding Verilog syntax, etc, but you can > also get the idea very quickly by examining an actual firmware design by > using the Quartus II editor. In addition, you?ll immediately be > learning how to use the Quartus II tool. In short, my view that the > absolute best way to learn is to get your feet wet immediately with the > tool that you will be using; i.e., Quartus II, to examine an existing > firmware design. > > The primary issue to understand about FPGA code, in my view, is to > realize from the start that each little section of code within the > firmware design runs in parallel with every other section. That is, the > code execution is not ?event driven? as it is in Windows programming nor > is it strictly running lines of code sequentially as in some languages > (except within each section of code in the firmare design). Because of > this it is actually easy to take one little section of code and examine > it carefully to see what it is doing, how it is doing it, and what > syntax is used to accomplish it. > > After you feel you understand a portion of it then you can make small > changes to it, compile it, and see what effect your change(s) have on > the performance of the firmware design by actually loading it into your > HPSDR rigs? FPGA. Plus you immediately gain experience in how to do all > that. Sure, you?ll make mistakes! But be assured that anything you do > is recoverable; you can?t hurt the FPGA by misprogramming it. > > 73, Joe K5SO > > On Aug 23, 2014, at 12:46 PM, Neal Campbell wrote: > >> Are there any good beginner courses on the internet? >> >> 73 >> >> Neal Campbell >> Abroham Neal LLC >> >> >> > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1408837411.0 From brian13434 at yahoo.co.uk Sun Aug 24 05:38:15 2014 From: brian13434 at yahoo.co.uk (Brian D) Date: Sun, 24 Aug 2014 13:38:15 +0100 Subject: [hpsdr] Angelia_v4.2 firmware release In-Reply-To: References: Message-ID: Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > Angelia_v4.2 firmware is available for download from > > http://k5so.com/HPSDR_downloads.html > Is this suitable for use in the ANAN range of tranceivers or does it need to be changed by Abhi for the different filter frequencies? -- Brian D G3VGZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1408883895.0 From k5so at valornet.com Sun Aug 24 06:30:01 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 24 Aug 2014 07:30:01 -0600 Subject: [hpsdr] Angelia_v4.2 firmware release In-Reply-To: References: Message-ID: Hi Brian, The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. The firmware uses correct switch-point frequencies for the Alex filter set, which is also the correct switch-point frequencies for the ANAN-series radios that have the correct windings on their filters. It is my understanding that later versions of the ANAN series radios use correct windings on their 10/12m filters so their switch points should be identical to those in Alex. Earlier versions of the ANAN series radios do not. The firmware ?patch? used initially by Abhi to correct the 10m low power output for some ANAN series radios is not the ideal method for correcting the issue of low power output on 10m on those earlier ANAN radios, as the issue is actually a hardware issue, not a firmware or software issue. If Abhi wishes to create a version of firmware that uses different switch points from Alex that?s his prerogative but you should be aware that the issue is not actually a firmware issue, it?s a hardware issue. The fact is that there should be only a single firmware version to use with each of the Hermes, Angelia, and Orion boards, respectively, regardless of whether the board are used in an ANAN-series configuration with the Apache Labs filters or in a stand alone configuration using Alex filters. The "correct fix? for ANAN radios that have the low power output issue on 10m is to rewind the filter toroids for the 10/12 m filters on those radios, not to patch the firmware or software to use switch points that are different from the Alex filter design. 73, Joe K5SO On Aug 24, 2014, at 6:38 AM, Brian D wrote: > Joe Martin K5SO wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> Angelia_v4.2 firmware is available for download from >> >> http://k5so.com/HPSDR_downloads.html >> > Is this suitable for use in the ANAN range of tranceivers or does it need to > be changed by Abhi for the different filter frequencies? > > -- > Brian D > G3VGZ > > --- > This email is free from viruses and malware because avast! Antivirus protection is active. > http://www.avast.com > 1408887001.0 From k5so at valornet.com Sun Aug 24 06:43:04 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 24 Aug 2014 07:43:04 -0600 Subject: [hpsdr] Angelia_v4.2 firmware release In-Reply-To: References: Message-ID: > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. Excuse me. A more accurate statement would?ve been: "The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience a lower maximum output power on 10m than you will if the windings are correct.? 73, Joe K5SO On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Brian, > > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. > > The firmware uses correct switch-point frequencies for the Alex filter set, which is also the correct switch-point frequencies for the ANAN-series radios that have the correct windings on their filters. It is my understanding that later versions of the ANAN series radios use correct windings on their 10/12m filters so their switch points should be identical to those in Alex. Earlier versions of the ANAN series radios do not. > > The firmware ?patch? used initially by Abhi to correct the 10m low power output for some ANAN series radios is not the ideal method for correcting the issue of low power output on 10m on those earlier ANAN radios, as the issue is actually a hardware issue, not a firmware or software issue. If Abhi wishes to create a version of firmware that uses different switch points from Alex that?s his prerogative but you should be aware that the issue is not actually a firmware issue, it?s a hardware issue. > > The fact is that there should be only a single firmware version to use with each of the Hermes, Angelia, and Orion boards, respectively, regardless of whether the board are used in an ANAN-series configuration with the Apache Labs filters or in a stand alone configuration using Alex filters. The "correct fix? for ANAN radios that have the low power output issue on 10m is to rewind the filter toroids for the 10/12 m filters on those radios, not to patch the firmware or software to use switch points that are different from the Alex filter design. > > > 73, Joe K5SO > > On Aug 24, 2014, at 6:38 AM, Brian D wrote: > >> Joe Martin K5SO wrote: >> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> All, >>> >>> Angelia_v4.2 firmware is available for download from >>> >>> http://k5so.com/HPSDR_downloads.html >>> >> Is this suitable for use in the ANAN range of tranceivers or does it need to >> be changed by Abhi for the different filter frequencies? >> >> -- >> Brian D >> G3VGZ >> >> --- >> This email is free from viruses and malware because avast! Antivirus protection is active. >> http://www.avast.com >> > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408887784.0 From bjablonski at att.net Sun Aug 24 11:33:14 2014 From: bjablonski at att.net (Barry Jablonski) Date: Sun, 24 Aug 2014 14:33:14 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> Message-ID: <53FA2FEA.1080501@att.net> Hi Joe, I should know this, but -- where is the FPGA source code located? Barry WB2ZXJ 1408905194.0 From wb9qzb_groups at yahoo.com Sun Aug 24 11:34:29 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Sun, 24 Aug 2014 11:34:29 -0700 Subject: [hpsdr] Banquet Speaker & Sunday Seminar Annouced at ARRL/TAPR DCC (Digital Communications Conference), Austin, TX, 9/5 - 9/7 In-Reply-To: <1408905113.46795.YahooMailNeo@web140204.mail.bf1.yahoo.com> References: <53EDF934.8040708@sbcglobal.net> <1408905113.46795.YahooMailNeo@web140204.mail.bf1.yahoo.com> Message-ID: <1408905269.81493.YahooMailNeo@web140204.mail.bf1.yahoo.com> The 2014 ARRL/TAPR DCC?Saturday Night Banquet Speaker & Topic?will be? Gerald Youngblood, K5SDR presenting?"Accidental Company, the making of Flex Radio" ----- Forwarded Message ----- From: Stan Horzepa To: tapr-announce at tapr.org Sent: Friday, August 15, 2014 7:12 AM Subject: [tapr-announce] DCC in 3 weeks The 2014 ?ARRL/TAPR DCC will be on Friday, September 5th through Sunday, September 7th at the Austin Marriott South in Austin, Texas. The DCC has two days of technical forums on Friday and Saturday and a concurrent introductory forum on Saturday.? On Saturday night, the banquet will feature an interesting speaker andthe Sunday morning seminar will be "Introduction to SoC FPGA Programming for Mixed Signal Systems" by Chris Testa, KD2BMH. There will be free tables in the demo room to demonstrate projects and vendors to demonstrate products. Time is running out, so those interested in attending should register for the DCC and make hotel reservations ASAP. More DCC information is available at:?www.tapr.org/dcc? ? _______________________________________________ tapr-announce mailing list -------------- next part -------------- An HTML attachment was scrubbed... URL: From pa5bw at xs4all.nl Sun Aug 24 11:55:16 2014 From: pa5bw at xs4all.nl (Ben Witvliet) Date: Sun, 24 Aug 2014 20:55:16 +0200 Subject: [hpsdr] QSK question Message-ID: <81f5d1436d8c0bb8218afb700688ca0a.squirrel@webmail.xs4all.nl> Dear all, I hesistating to switch from my FT990 to an ANAN-200D as my primary RIG as I love the superb quality of the HPSDR receiver and I got hooked on the overview that the waterfall display offer. But I'm also a fanatic DX-er and CW QSK adept, and therefore CAN't LIVE without QSK ;-) I had Erik PA3DES demonstrate the ANAN-10D (HPSDR Hermes) to me with QSK on, but we could not get it working properly. Of course with paddle and headphones connected directly to the ANAN hardware. The switching seems fast enough, but after every dash or dit the AGC of the receiver has to slowly come back to normal, making it impossible to hear anything in between the CW symbols. (1) Any experienced HPSDR user and CW-er here that can tell me what settings we have wrong? (2) Any HPSDR user in The Netherlands that has experience with HF DX-ing in CW and with QSK willing to give a demo of his HPSDR station? Kindest regards, 73, Ben PE5B / PA5BW / 5R8DS 1408906516.0 From k5so at valornet.com Sun Aug 24 13:07:25 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 24 Aug 2014 14:07:25 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53FA2FEA.1080501@att.net> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> <53FA2FEA.1080501@att.net> Message-ID: <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> Hi Barry, The source code for all of the OpenHPSDR boards is located on the SVN. For Hermes as an example, the source code can be found at http://svn.tapr.org/repos_sdr_hpsdr/trunk/Hermes/Source/Hermes_v2.9/Heremes_v2.9.qar Similarly for Metis, Ozy, Mercury, and Penelope. For Angelia and Orion the source code is available on both my website download page within the firmware download zipped folder http://k5so.com/HPSDR_downloads.html and the Apache Labs download page (sorry, I don?t have the URL for that handy). The source code is generally stored in the form of a *.qar file, which is the Quartus II archive file format. It can be opened and edited and re-compiled if you wish using Quartus II. 73, Joe K5SO On Aug 24, 2014, at 12:33 PM, Barry Jablonski wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Joe, > > I should know this, but -- where is the FPGA source code located? > > Barry > WB2ZXJ 1408910845.0 From bjablonski at att.net Sun Aug 24 13:20:31 2014 From: bjablonski at att.net (Barry Jablonski) Date: Sun, 24 Aug 2014 16:20:31 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> <53FA2FEA.1080501@att.net> <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> Message-ID: <53FA490F.9040102@att.net> Thank you very much Joe for the info. I guess that I will have to reinstall Tortoise SVN on the Win7/64 Pro machine. It was on the old XP/32 SP3 box, but I failed to bring it forward. Barry WB2ZXJ On 8/24/2014 4:07 PM, Joe Martin K5SO wrote: > Hi Barry, > > The source code for all of the OpenHPSDR boards is located on the SVN. For Hermes as an example, the source code can be found at > > http://svn.tapr.org/repos_sdr_hpsdr/trunk/Hermes/Source/Hermes_v2.9/Heremes_v2.9.qar > > Similarly for Metis, Ozy, Mercury, and Penelope. > > For Angelia and Orion the source code is available on both my website download page within the firmware download zipped folder > > http://k5so.com/HPSDR_downloads.html > > and the Apache Labs download page (sorry, I don?t have the URL for that handy). > > The source code is generally stored in the form of a *.qar file, which is the Quartus II archive file format. It can be opened and edited and re-compiled if you wish using Quartus II. > > 73, Joe K5SO > > On Aug 24, 2014, at 12:33 PM, Barry Jablonski wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Joe, >> >> I should know this, but -- where is the FPGA source code located? >> >> Barry >> WB2ZXJ > 1408911631.0 From lstoskopf at cox.net Sun Aug 24 15:52:53 2014 From: lstoskopf at cox.net (lstoskopf at cox.net) Date: Sun, 24 Aug 2014 18:52:53 -0400 Subject: [hpsdr] Buy Jetson board? Message-ID: <20140824185253.KI4BB.171489.imail@eastrmwml114> Scotty has the new processor board coming out for his boards and I'm on board (!) when they are out. Ending up here with a pile of development boards (I don't mind). Is there enough SDR coming out/planned to buy a Jetson board and be a passive user or wait for the bigger version or ????????? Fun to try to keep up with the bleeding edge. N0UU 1408920773.0 From kv0s.dave at gmail.com Sun Aug 24 16:48:36 2014 From: kv0s.dave at gmail.com (Dave Larsen) Date: Sun, 24 Aug 2014 18:48:36 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53FA490F.9040102@att.net> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> <53FA2FEA.1080501@att.net> <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> <53FA490F.9040102@att.net> Message-ID: Barry - Just to let you and others know SVN Software works but you can download files one at time from the web interface and since all tha verlog file are in a *.qar file it may be easier to just use the web interface svn.tapr.org Dave KV0S On Aug 24, 2014 3:20 PM, "Barry Jablonski" wrote: > Thank you very much Joe for the info. > > I guess that I will have to reinstall Tortoise SVN on the Win7/64 Pro > machine. It was on the old XP/32 SP3 box, but I failed to bring it forward. > > Barry > WB2ZXJ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gokoyev+k3it at gmail.com Mon Aug 25 08:43:55 2014 From: gokoyev+k3it at gmail.com (k3it) Date: Mon, 25 Aug 2014 11:43:55 -0400 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) Message-ID: Is there an easy way to identify which radios need a correction for 10/12m coils? Vasiliy On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > The short answer is yes, but if you happen to have an ANAN-series radio > that has incorrect number of windings on the 10/12m filter toroids you will > experience low output power on 10m. > > > Excuse me. A more accurate statement would?ve been: > > "The short answer is yes, but if you happen to have an ANAN-series radio > that has incorrect number of windings on the 10/12m filter toroids you will > experience a lower maximum output power on 10m than you will if the > windings are correct.? > > 73, Joe K5SO > > > On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: > > > ***** High Performance Software Defined Radio Discussion List ***** > > > > Hi Brian, > > > > The short answer is yes, but if you happen to have an ANAN-series radio > that has incorrect number of windings on the 10/12m filter toroids you will > experience low output power on 10m. > > > > The firmware uses correct switch-point frequencies for the Alex filter > set, which is also the correct switch-point frequencies for the ANAN-series > radios that have the correct windings on their filters. It is my > understanding that later versions of the ANAN series radios use correct > windings on their 10/12m filters so their switch points should be identical > to those in Alex. Earlier versions of the ANAN series radios do not. > > > > The firmware ?patch? used initially by Abhi to correct the 10m low power > output for some ANAN series radios is not the ideal method for correcting > the issue of low power output on 10m on those earlier ANAN radios, as the > issue is actually a hardware issue, not a firmware or software issue. If > Abhi wishes to create a version of firmware that uses different switch > points from Alex that?s his prerogative but you should be aware that the > issue is not actually a firmware issue, it?s a hardware issue. > > > > The fact is that there should be only a single firmware version to use > with each of the Hermes, Angelia, and Orion boards, respectively, > regardless of whether the board are used in an ANAN-series configuration > with the Apache Labs filters or in a stand alone configuration using Alex > filters. The "correct fix? for ANAN radios that have the low power output > issue on 10m is to rewind the filter toroids for the 10/12 m filters on > those radios, not to patch the firmware or software to use switch points > that are different from the Alex filter design. > > > > > > 73, Joe K5SO > > > > On Aug 24, 2014, at 6:38 AM, Brian D wrote: > > > >> Joe Martin K5SO wrote: > >> > >>> ***** High Performance Software Defined Radio Discussion List ***** > >>> > >>> All, > >>> > >>> Angelia_v4.2 firmware is available for download from > >>> > >>> http://k5so.com/HPSDR_downloads.html > >>> > >> Is this suitable for use in the ANAN range of tranceivers or does it > need to > >> be changed by Abhi for the different filter frequencies? > >> > >> -- > >> Brian D > >> G3VGZ > >> > >> --- > >> This email is free from viruses and malware because avast! Antivirus > protection is active. > >> http://www.avast.com > >> > > > > _______________________________________________ > > HPSDR Discussion List > > To post msg: hpsdr at openhpsdr.org > > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > > HPSDR web page: http://openhpsdr.org > > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 25 09:25:10 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 25 Aug 2014 10:25:10 -0600 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: It is my understanding that L15 should have 8 turns and L16 should have 9 turns, both of 22 AWG wire. If they do not, then you may observe a lower output power on 10m Tx than you would otherwise. 73, Joe K5SO On Aug 25, 2014, at 9:43 AM, k3it wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Is there an easy way to identify which radios need a correction for 10/12m coils? > > Vasiliy > > > On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. > > > Excuse me. A more accurate statement would?ve been: > > "The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience a lower maximum output power on 10m than you will if the windings are correct.? > > 73, Joe K5SO > > > On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: > > > ***** High Performance Software Defined Radio Discussion List ***** > > > > Hi Brian, > > > > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. > > > > The firmware uses correct switch-point frequencies for the Alex filter set, which is also the correct switch-point frequencies for the ANAN-series radios that have the correct windings on their filters. It is my understanding that later versions of the ANAN series radios use correct windings on their 10/12m filters so their switch points should be identical to those in Alex. Earlier versions of the ANAN series radios do not. > > > > The firmware ?patch? used initially by Abhi to correct the 10m low power output for some ANAN series radios is not the ideal method for correcting the issue of low power output on 10m on those earlier ANAN radios, as the issue is actually a hardware issue, not a firmware or software issue. If Abhi wishes to create a version of firmware that uses different switch points from Alex that?s his prerogative but you should be aware that the issue is not actually a firmware issue, it?s a hardware issue. > > > > The fact is that there should be only a single firmware version to use with each of the Hermes, Angelia, and Orion boards, respectively, regardless of whether the board are used in an ANAN-series configuration with the Apache Labs filters or in a stand alone configuration using Alex filters. The "correct fix? for ANAN radios that have the low power output issue on 10m is to rewind the filter toroids for the 10/12 m filters on those radios, not to patch the firmware or software to use switch points that are different from the Alex filter design. > > > > > > 73, Joe K5SO > > > > On Aug 24, 2014, at 6:38 AM, Brian D wrote: > > > >> Joe Martin K5SO wrote: > >> > >>> ***** High Performance Software Defined Radio Discussion List ***** > >>> > >>> All, > >>> > >>> Angelia_v4.2 firmware is available for download from > >>> > >>> http://k5so.com/HPSDR_downloads.html > >>> > >> Is this suitable for use in the ANAN range of tranceivers or does it need to > >> be changed by Abhi for the different filter frequencies? > >> > >> -- > >> Brian D > >> G3VGZ > >> > >> --- > >> This email is free from viruses and malware because avast! Antivirus protection is active. > >> http://www.avast.com > >> > > > > _______________________________________________ > > HPSDR Discussion List > > To post msg: hpsdr at openhpsdr.org > > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > > HPSDR web page: http://openhpsdr.org > > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 25 09:36:31 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 25 Aug 2014 10:36:31 -0600 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: <2E9C3C33-83C3-4A84-A93C-24EEBD89753C@valornet.com> References: <2E9C3C33-83C3-4A84-A93C-24EEBD89753C@valornet.com> Message-ID: It is my further understanding that radios that have the 100W PA and were shipped after March 2014 have the correct number of windings on the 10/12m LPF toroids. 73, Joe K5SO On Aug 25, 2014, at 10:25 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > It is my understanding that L15 should have 8 turns and L16 should have 9 turns, both of 22 AWG wire. > > If they do not, then you may observe a lower output power on 10m Tx than you would otherwise. > > 73, Joe K5SO > > > On Aug 25, 2014, at 9:43 AM, k3it wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Is there an easy way to identify which radios need a correction for 10/12m coils? >> >> Vasiliy > 1408984591.0 From abhiarunoday at gmail.com Mon Aug 25 09:53:03 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Mon, 25 Aug 2014 22:23:03 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: Hi Vasiliy, The Original Angelia/Orion firmware extends the 17/15M LPF upto 27Mhz so that 12M is incorporated within this LPF, the Hermes firmware is modified to the (B) version by me to enable this, Firmware that you download from the Apache website incorporates this change, 73s, Abhi On Mon, Aug 25, 2014 at 9:13 PM, k3it wrote: > Is there an easy way to identify which radios need a correction for 10/12m > coils? > > Vasiliy > > > On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO > wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> >> >> Excuse me. A more accurate statement would?ve been: >> >> "The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience a lower maximum output power on 10m than you will if the >> windings are correct.? >> >> 73, Joe K5SO >> >> >> On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: >> >> > ***** High Performance Software Defined Radio Discussion List ***** >> > >> > Hi Brian, >> > >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> > >> > The firmware uses correct switch-point frequencies for the Alex filter >> set, which is also the correct switch-point frequencies for the ANAN-series >> radios that have the correct windings on their filters. It is my >> understanding that later versions of the ANAN series radios use correct >> windings on their 10/12m filters so their switch points should be identical >> to those in Alex. Earlier versions of the ANAN series radios do not. >> > >> > The firmware ?patch? used initially by Abhi to correct the 10m low >> power output for some ANAN series radios is not the ideal method for >> correcting the issue of low power output on 10m on those earlier ANAN >> radios, as the issue is actually a hardware issue, not a firmware or >> software issue. If Abhi wishes to create a version of firmware that uses >> different switch points from Alex that?s his prerogative but you should be >> aware that the issue is not actually a firmware issue, it?s a hardware >> issue. >> > >> > The fact is that there should be only a single firmware version to use >> with each of the Hermes, Angelia, and Orion boards, respectively, >> regardless of whether the board are used in an ANAN-series configuration >> with the Apache Labs filters or in a stand alone configuration using Alex >> filters. The "correct fix? for ANAN radios that have the low power output >> issue on 10m is to rewind the filter toroids for the 10/12 m filters on >> those radios, not to patch the firmware or software to use switch points >> that are different from the Alex filter design. >> > >> > >> > 73, Joe K5SO >> > >> > On Aug 24, 2014, at 6:38 AM, Brian D wrote: >> > >> >> Joe Martin K5SO wrote: >> >> >> >>> ***** High Performance Software Defined Radio Discussion List ***** >> >>> >> >>> All, >> >>> >> >>> Angelia_v4.2 firmware is available for download from >> >>> >> >>> http://k5so.com/HPSDR_downloads.html >> >>> >> >> Is this suitable for use in the ANAN range of tranceivers or does it >> need to >> >> be changed by Abhi for the different filter frequencies? >> >> >> >> -- >> >> Brian D >> >> G3VGZ >> >> >> >> --- >> >> This email is free from viruses and malware because avast! Antivirus >> protection is active. >> >> http://www.avast.com >> >> >> > >> > _______________________________________________ >> > HPSDR Discussion List >> > To post msg: hpsdr at openhpsdr.org >> > Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> > HPSDR web page: http://openhpsdr.org >> > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhiarunoday at gmail.com Mon Aug 25 10:22:48 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Mon, 25 Aug 2014 22:52:48 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this, 73s, Abhi On Monday, August 25, 2014, k3it wrote: > Is there an easy way to identify which radios need a correction for 10/12m > coils? > > Vasiliy > > > On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO > wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> >> >> Excuse me. A more accurate statement would?ve been: >> >> "The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience a lower maximum output power on 10m than you will if the >> windings are correct.? >> >> 73, Joe K5SO >> >> >> On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: >> >> > ***** High Performance Software Defined Radio Discussion List ***** >> > >> > Hi Brian, >> > >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> > >> > The firmware uses correct switch-point frequencies for the Alex filter >> set, which is also the correct switch-point frequencies for the ANAN-series >> radios that have the correct windings on their filters. It is my >> understanding that later versions of the ANAN series radios use correct >> windings on their 10/12m filters so their switch points should be identical >> to those in Alex. Earlier versions of the ANAN series radios do not. >> > >> > The firmware ?patch? used initially by Abhi to correct the 10m low >> power output for some ANAN series radios is not the ideal method for >> correcting the issue of low power output on 10m on those earlier ANAN >> radios, as the issue is actually a hardware issue, not a firmware or >> software issue. If Abhi wishes to create a version of firmware that uses >> different switch points from Alex that?s his prerogative but you should be >> aware that the issue is not actually a firmware issue, it?s a hardware >> issue. >> > >> > The fact is that there should be only a single firmware version to use >> with each of the Hermes, Angelia, and Orion boards, respectively, >> regardless of whether the board are used in an ANAN-series configuration >> with the Apache Labs filters or in a stand alone configuration using Alex >> filters. The "correct fix? for ANAN radios that have the low power output >> issue on 10m is to rewind the filter toroids for the 10/12 m filters on >> those radios, not to patch the firmware or software to use switch points >> that are different from the Alex filter design. >> > >> > >> > 73, Joe K5SO >> > >> > On Aug 24, 2014, at 6:38 AM, Brian D wrote: >> > >> >> Joe Martin K5SO > > wrote: >> >> >> >>> ***** High Performance Software Defined Radio Discussion List ***** >> >>> >> >>> All, >> >>> >> >>> Angelia_v4.2 firmware is available for download from >> >>> >> >>> http://k5so.com/HPSDR_downloads.html >> >>> >> >> Is this suitable for use in the ANAN range of tranceivers or does it >> need to >> >> be changed by Abhi for the different filter frequencies? >> >> >> >> -- >> >> Brian D >> >> G3VGZ >> >> >> >> --- >> >> This email is free from viruses and malware because avast! Antivirus >> protection is active. >> >> http://www.avast.com >> >> >> > >> > _______________________________________________ >> > HPSDR Discussion List >> > To post msg: hpsdr at openhpsdr.org >> >> > Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> > HPSDR web page: http://openhpsdr.org >> > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjablonski at att.net Mon Aug 25 10:31:25 2014 From: bjablonski at att.net (Barry Jablonski) Date: Mon, 25 Aug 2014 13:31:25 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53FB72ED.8060107@att.net> Thanks for that information Dave. I'm mainly interested in the Hermes FPGA code and this will save me time. I also just found out I will have to downgrade Quartus II from v14 to v13.1 since the latest version has dropped support for Cyclone III devices. Barry WB2ZXJ 1408987885.0 From mstangelo at comcast.net Mon Aug 25 12:49:23 2014 From: mstangelo at comcast.net (mstangelo at comcast.net) Date: Mon, 25 Aug 2014 19:49:23 +0000 (UTC) Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> Abhi, You responded with: "Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this," You also had an issue low power with 12M. Do we need your special code to switcg in different LP filters for the 12 Meter band? Mike N2MS ----- Original Message ----- From: Abhi A To: k3it Cc: HPSDR list Sent: Mon, 25 Aug 2014 17:22:48 -0000 (UTC) Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** 1408996163.0 From gregg.w6izt1 at gmail.com Mon Aug 25 12:55:49 2014 From: gregg.w6izt1 at gmail.com (Gregg W6IZT) Date: Mon, 25 Aug 2014 15:55:49 -0400 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> References: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> Message-ID: <047601cfc09e$91ea2240$b5be66c0$@gmail.com> I had the low power issue on 12 m and a change to the FW resolved it. I'd prefer to address a HW problem in HW by adjusting the inductors in the LPF to have the correct number of turns. I now have that information on the correct number of turns for the inductors in question. Question: Will I need to change the FW if I correct the inductors? Gregg W6IZT -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of mstangelo at comcast.net Sent: Monday, August 25, 2014 3:49 PM To: Abhi A Cc: HPSDR list Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** Abhi, You responded with: "Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this," You also had an issue low power with 12M. Do we need your special code to switcg in different LP filters for the 12 Meter band? Mike N2MS ----- Original Message ----- From: Abhi A To: k3it Cc: HPSDR list Sent: Mon, 25 Aug 2014 17:22:48 -0000 (UTC) Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408996549.0 From ka6tya at arrl.net Mon Aug 25 13:22:35 2014 From: ka6tya at arrl.net (Pat McGrath) Date: Mon, 25 Aug 2014 13:22:35 -0700 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: <047601cfc09e$91ea2240$b5be66c0$@gmail.com> References: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> <047601cfc09e$91ea2240$b5be66c0$@gmail.com> Message-ID: <000301cfc0a2$4ed683f0$ec838bd0$@arrl.net> Abhi A Will your company permanently fix the problem? -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Gregg W6IZT Sent: Monday, August 25, 2014 12:56 PM To: mstangelo at comcast.net; 'Abhi A' Cc: 'HPSDR list' Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** I had the low power issue on 12 m and a change to the FW resolved it. I'd prefer to address a HW problem in HW by adjusting the inductors in the LPF to have the correct number of turns. I now have that information on the correct number of turns for the inductors in question. Question: Will I need to change the FW if I correct the inductors? Gregg W6IZT -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of mstangelo at comcast.net Sent: Monday, August 25, 2014 3:49 PM To: Abhi A Cc: HPSDR list Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** Abhi, You responded with: "Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this," You also had an issue low power with 12M. Do we need your special code to switcg in different LP filters for the 12 Meter band? Mike N2MS ----- Original Message ----- From: Abhi A To: k3it Cc: HPSDR list Sent: Mon, 25 Aug 2014 17:22:48 -0000 (UTC) Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408998155.0 From abhiarunoday at gmail.com Mon Aug 25 20:46:58 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Tue, 26 Aug 2014 09:16:58 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) Message-ID: Hi Guys, I think there is some confusion here, all ANAN radios use the 17/15M LPF on 12M as well, changing the coils on the 10M LPF does not effect the 12M output, The change in the 10M LPF was to prevent low output on the 10M band in some radios, if you are not experiencing low power on 10M this does not effect you, The Orion and Angelia firmware already have this change coded in, the Original Hermes firmware does not, hence, Apache releases a B version which incorporates this change, 73s, Abhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Mon Aug 25 21:53:53 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Mon, 25 Aug 2014 23:53:53 -0500 Subject: [hpsdr] Fwd: RE: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: Is it just me or does the fwd pwr TX meter seem to be to be reading lower than it should with this release? I was checking power outputs and it seems to be about 15 watts lower than reality. Is this just me? I was trying to adjust output power and that's when I realized it. I reset databases just to be sure. I didn't notice this on 3.2.17. 73, Jae - K5JAE -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhiarunoday at gmail.com Mon Aug 25 22:38:55 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Tue, 26 Aug 2014 11:08:55 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) Message-ID: Further update and correction: The 10M Coil update also fixes the 12M low power output, however, using the 17/15M LPF for 12M also works, The current Orion firmware uses the 10M LPF for 12M, all 200Ds shipped have the LPF change incorporated, The Angelia and Hermes (B) Firmware uses the 17/15M LPF for 12M, I believe all radios shipped from March 2014 as Joe indicated have this change incorporated, In case you are experiencing low output on 12/10M please contact Apache Support and we will be happy to assist in resolving this issue, 73s, Abhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian13434 at yahoo.co.uk Tue Aug 26 02:54:53 2014 From: brian13434 at yahoo.co.uk (Brian D) Date: Tue, 26 Aug 2014 10:54:53 +0100 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: Jae Stutzman wrote: > Is it just me or does the fwd pwr TX meter seem to be to be reading lower > than it should with this release? I was checking power outputs and it > seems to be about 15 watts lower than reality. Is this just me? I was > trying to adjust output power and that's when I realized it. I reset > databases just to be sure. I didn't notice this on 3.2.17. I haven't noticed it reading low but I've had several times it reading NaN for VSWR when tuning into the goood match of my test load. Not sure at this stage if it is the new version of HPSDR or my recent firmware upgrade to 4.2 (angelia). -- Brian D G3VGZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1409046893.0 From k5jae at stutzman.net Tue Aug 26 05:38:52 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Tue, 26 Aug 2014 07:38:52 -0500 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: I should have mentioned that I recently upgraded to 4.2 Angelia as well. So it could be either. I'll try downgrading back to 4.1 to see if that changes anything. I noticed it with TUN and it was reading out about 85W for each band. I was originally trying to find out if I was affected by the 10M winding issue. On Tue, Aug 26, 2014 at 4:54 AM, Brian D wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Jae Stutzman wrote: > > > Is it just me or does the fwd pwr TX meter seem to be to be reading lower > > than it should with this release? I was checking power outputs and it > > seems to be about 15 watts lower than reality. Is this just me? I was > > trying to adjust output power and that's when I realized it. I reset > > databases just to be sure. I didn't notice this on 3.2.17. > > I haven't noticed it reading low but I've had several times it reading NaN > for VSWR when tuning into the goood match of my test load. Not sure at this > stage if it is the new version of HPSDR or my recent firmware upgrade to > 4.2 > (angelia). > > > -- > Brian D > G3VGZ > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernd.gasser at tele2.at Tue Aug 26 06:01:36 2014 From: bernd.gasser at tele2.at (Bernd Gasser) Date: Tue, 26 Aug 2014 15:01:36 +0200 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <008001cfc12d$dea6b4b0$9bf41e10$@tele2.at> Hi Hermann et al, after seeing all your interesting messages I was also infected by the cuda-virus and ordered a Jetson TK1 to play with. So far I managed to set it up with Qt5.4 and cuda-6.0 installed and I have successfully compiled cuSDR64 and ghpsdr-alex on it which both seems to run fine with a little high CPU-load. (cuSDR64 shows abt 155%). When looking at the shared libraries mapped to the running binary I noticed it is still using the 'standard libfftw3' library instead of the ones optimized for the TEGRA 192 GPU cores supplied with cuda-6.0. UID PID PPID C STIME TTY TIME CMD ubuntu 2942 2607 99 12:07 pts/4 00:38:25 ./cuSDR64 ubuntu at tegra-ubuntu:/proc/2942$ grep fftw maps b6665000-b67ad000 r-xp 00000000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 b67ad000-b67b4000 ---p 00148000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 b67b4000-b67bc000 r--p 00147000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 b67bc000-b67bd000 rw-p 0014f000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 What would be the required change in the build environment to make use of the cuda-6.0 libraries in /usr/local/cuda-6.0/lib/libcufftw* ? - Has anyone done this yet and could give me some pointers? tnx & 73, Bernd/OE1ACM -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von Hermann Gesendet: Montag, 18. August 2014 13:24 An: Chris Smith; hpsdr at lists.openhpsdr.org Betreff: Re: [hpsdr] 20140126cuSDR64 & TK1 ***** High Performance Software Defined Radio Discussion List ***** 1409058096.0 From gokoyev+k3it at gmail.com Tue Aug 26 06:23:48 2014 From: gokoyev+k3it at gmail.com (k3it) Date: Tue, 26 Aug 2014 09:23:48 -0400 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <008001cfc12d$dea6b4b0$9bf41e10$@tele2.at> References: <20140817163704.A6AAD48278@diego.dreamhost.com> <008001cfc12d$dea6b4b0$9bf41e10$@tele2.at> Message-ID: Here is a link that describes what needs to be done to convert to cufftw http://docs.nvidia.com/cuda/cufft/index.html#fftw-supported-interface But this looks too easy to be true :) I haven't tried it. Also running Jetson board here with gphpsdr3 73 Vasiliy On Tue, Aug 26, 2014 at 9:01 AM, Bernd Gasser wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Hermann et al, > after seeing all your interesting messages I was also infected by the > cuda-virus and ordered a Jetson TK1 to play with. > > So far I managed to set it up with Qt5.4 and cuda-6.0 installed and I have > successfully compiled cuSDR64 and ghpsdr-alex on it which both seems to run > fine with a little high CPU-load. (cuSDR64 shows abt 155%). > > When looking at the shared libraries mapped to the running binary I noticed > it is still using the 'standard libfftw3' library instead of the ones > optimized for the TEGRA 192 GPU cores supplied with cuda-6.0. > > > UID PID PPID C STIME TTY TIME CMD > ubuntu 2942 2607 99 12:07 pts/4 00:38:25 ./cuSDR64 > > ubuntu at tegra-ubuntu:/proc/2942$ grep fftw maps > b6665000-b67ad000 r-xp 00000000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > b67ad000-b67b4000 ---p 00148000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > b67b4000-b67bc000 r--p 00147000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > b67bc000-b67bd000 rw-p 0014f000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > > What would be the required change in the build environment to make use of > the cuda-6.0 libraries in /usr/local/cuda-6.0/lib/libcufftw* ? - Has > anyone > done this yet and could give me some pointers? > > tnx & 73, > Bernd/OE1ACM > > > > > > > > -----Urspr?ngliche Nachricht----- > Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von > Hermann > Gesendet: Montag, 18. August 2014 13:24 > An: Chris Smith; hpsdr at lists.openhpsdr.org > Betreff: Re: [hpsdr] 20140126cuSDR64 & TK1 > > ***** High Performance Software Defined Radio Discussion List ***** > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnlaur at gmail.com Tue Aug 26 08:08:04 2014 From: johnlaur at gmail.com (John Laur) Date: Tue, 26 Aug 2014 10:08:04 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: Ideas for discussion: First, isn't this similar to the architecture that has been implemented by PA3FWM's wideband websdr for some time? ADC->FPGA->Ethernet->FFT with GPU and then individual receivers only have to grab the bins and do an IFFT? If so, it's a clear winner as far as scaling the capabilities go. I am very excited to see the excitement for it. But I am concerned with the discussion dwelling around the Jetson board as being central and essential to this architecture long-term although I do think it is valuable as a motivator. For a hardware architecture that will hang around for a while and be the most compatible, I would like to discuss the option of designing instead for regular (non-mini) PCI-e. While it's great to have these 'fun-size' SBC's there is really nothing that I have seen to conclude that NVidia or a 3rd party will continue to ship such a thing as a developer or retail product with extremely similar architecture and form factor over the long term. So unless there is someone who wants to keep up with the hassle of actually integrating NVidia silicon onto an HPSDR board and making a wholly integrated system a la the Flex-6k, I do not think it is worth exploring too far into that paradigm. Designing for the Jetson's mini-pcie interface would severely limit future flexibility should the product be dropped and limit the use of the HPSDR hardware in cases where mini-pcie is not available on a board with a suitable CUDA GPU. Plus, Jetson itself has a huge disadvantage (for the HPSDR server application) of having only a single Ethernet interface. I understand that there is still 16Mbps of bandwidth 'left over' (and that the interface itself is full duplex) but that is an awfully limiting margin considering the possibilities that exist with the architecture. Yes; one could be added on USB without occupying the mini-PCIe, but at the expense of the limited CPU resources. Running ethernet interfaces at 99% capacity is a tricky business anyway. It would be nice to simply eliminate that challenge. There is one thing we can be sure of though: NVidia will continue to ship regular PCI-e graphics cards for the foreseeable future. Depending on the version of CUDA required, an inexpensive NVidia GeForce card will likely exceed Jetson's performance by quite a lot. A small dedicated system with dual PCIe slots and a GPU can be designed and built with specifications exceeding those of the Jetson board at similar cost, and the same architecture can be implemented. I do not see that the Jetson has any advantage over such system other than perhaps power consumption or having fixed design. The problem of power consumption is likely not to be a large concern in this application, and the second problem can be eliminated by specifying a tested reference design. * PCI-e is the fastest common interface available. Current standards take speeds to 250gbps (PCI-e 4.0 x16), and even the lowest common denominator (PCI-e 1.0 1x) is still 2gbps. * PCI-e can be bridged to Mini-PCIe, Thunderbolt, or Expresscard interfaces with off-the-shelf hardware. * PCI-e supports DMA, RDMA, and peer to peer data transfer. Data can be moved from HPDSR to GPU without involving the CPU. A passive PCI-e backplane could be used as a future replacement for Atlas with the ability to use off the shelf parts. * PCI-e is easy to interface in the modern Altera FPGAs with hardware controllers and does not require the difficult task of writing IP for 3rd party interface chips (Existing IP for things like USB 3.0 controllers and 10gbE chips are licensed and generally not compatible with open-source licenses. I believe this is one of the major pain points with the current HPSDR FPGA efforts.) * PCI-e is generally backwards (and forwards!) compatible. So modern high-bandwidth hardware can be designed and still used with older or less powerful hosts. An external interface of some sort has the advantage that the RF bits can be somewhat isolated from the noisy computer bits, but there are ways to mitigate that and still use PCI-e, such as using a case design that ensures the RF side is well shielded. The design could also be broken into two parts with the ADC/DAC/Clocks isolated and connected to the FPGA on a PCI-e card by means of line driver ICs and off-the-shelf cables. Any thoughts from those more involved with the software or hardware design? 73, John KF5SAB On Fri, Aug 22, 2014 at 10:31 PM, Phil Harman wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Marc, > > Thanks for your email. > > We still have a way to go with fully proving the DFC idea but so far its looking good. > > We actually had this discussion a few minutes ago during the weekly Teamspeak session. > > Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. > > What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. > > What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. > > With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. > > If such a PCB design is of interest to you then please lets discuss further. > > 73 Phil....VK6PH > > > -----Original Message----- From: Marc Lalonde > Sent: Saturday, August 23, 2014 10:31 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > guess some one already work on a ADC /DAC Board that go on the expansion > connector of the DEV kit ? > seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA > as Glue logic.. > > that may remove the LAN / PHY from equation and permit made nice self > contained platform ;-) > > if no one yet ,i may willing to help work on this ,i was a senior PCB > designer whit some design backgrond .. > > Best 73! > Marc VE2OLM 1409065684.0 From k5so at valornet.com Tue Aug 26 09:35:24 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Tue, 26 Aug 2014 10:35:24 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <3AD73732-607A-4AB5-96C3-5B78FB0B1477@valornet.com> Hi John, I completely agree with your analysis and have in fact privately expressed to several people my concern regarding use of a (marginally powerful) single board computer in the mix. But keep in mind that the new protocol that Phil is contemplating will work fine with either a single powerful computer (SBC) connected to the hardware OR with a high performance computer connected to the hardware as we have traditionally done. Therefore the SBC development activity underway doesn?t limit things at all for those of us who would prefer to use a single high performance computer instead. Users of a single high performance computer can still exploit the new protocol and realize the same flexibility and performance benefits that Phil mentioned that are associated with the new proposed ethernet protocol. The Jetson board SBC approach is simply an activity that is running in parallel with the original architecture scheme. Whether you wish to use an SBC configuration or not is entirely optional and open to your personal preference. I?ve come to realize that we?re not losing anything at all by having some people working on SBC configurations in order to have low-performance hand held devices able to interface the hardware (if that happens to be your personal interest). 73, Joe K5SO 1409070924.0 From dc6ny at gmx.de Tue Aug 26 09:36:24 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Tue, 26 Aug 2014 18:36:24 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <000001cfc14b$e0b5c2f0$a22148d0$@de> Nice reasoning, John. Thanks. 73, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von John Laur Gesendet: Dienstag, 26. August 2014 17:08 An: HPSDR list Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Ideas for discussion: First, isn't this similar to the architecture that has been implemented by PA3FWM's wideband websdr for some time? ADC->FPGA->Ethernet->FFT with GPU and then individual receivers only have to grab the bins and do an IFFT? If so, it's a clear winner as far as scaling the capabilities go. I am very excited to see the excitement for it. But I am concerned with the discussion dwelling around the Jetson board as being central and essential to this architecture long-term although I do think it is valuable as a motivator. For a hardware architecture that will hang around for a while and be the most compatible, I would like to discuss the option of designing instead for regular (non-mini) PCI-e. While it's great to have these 'fun-size' SBC's there is really nothing that I have seen to conclude that NVidia or a 3rd party will continue to ship such a thing as a developer or retail product with extremely similar architecture and form factor over the long term. So unless there is someone who wants to keep up with the hassle of actually integrating NVidia silicon onto an HPSDR board and making a wholly integrated system a la the Flex-6k, I do not think it is worth exploring too far into that paradigm. Designing for the Jetson's mini-pcie interface would severely limit future flexibility should the product be dropped and limit the use of the HPSDR hardware in cases where mini-pcie is not available on a board with a suitable CUDA GPU. Plus, Jetson itself has a huge disadvantage (for the HPSDR server application) of having only a single Ethernet interface. I understand that there is still 16Mbps of bandwidth 'left over' (and that the interface itself is full duplex) but that is an awfully limiting margin considering the possibilities that exist with the architecture. Yes; one could be added on USB without occupying the mini-PCIe, but at the expense of the limited CPU resources. Running ethernet interfaces at 99% capacity is a tricky business anyway. It would be nice to simply eliminate that challenge. There is one thing we can be sure of though: NVidia will continue to ship regular PCI-e graphics cards for the foreseeable future. Depending on the version of CUDA required, an inexpensive NVidia GeForce card will likely exceed Jetson's performance by quite a lot. A small dedicated system with dual PCIe slots and a GPU can be designed and built with specifications exceeding those of the Jetson board at similar cost, and the same architecture can be implemented. I do not see that the Jetson has any advantage over such system other than perhaps power consumption or having fixed design. The problem of power consumption is likely not to be a large concern in this application, and the second problem can be eliminated by specifying a tested reference design. * PCI-e is the fastest common interface available. Current standards take speeds to 250gbps (PCI-e 4.0 x16), and even the lowest common denominator (PCI-e 1.0 1x) is still 2gbps. * PCI-e can be bridged to Mini-PCIe, Thunderbolt, or Expresscard interfaces with off-the-shelf hardware. * PCI-e supports DMA, RDMA, and peer to peer data transfer. Data can be moved from HPDSR to GPU without involving the CPU. A passive PCI-e backplane could be used as a future replacement for Atlas with the ability to use off the shelf parts. * PCI-e is easy to interface in the modern Altera FPGAs with hardware controllers and does not require the difficult task of writing IP for 3rd party interface chips (Existing IP for things like USB 3.0 controllers and 10gbE chips are licensed and generally not compatible with open-source licenses. I believe this is one of the major pain points with the current HPSDR FPGA efforts.) * PCI-e is generally backwards (and forwards!) compatible. So modern high-bandwidth hardware can be designed and still used with older or less powerful hosts. An external interface of some sort has the advantage that the RF bits can be somewhat isolated from the noisy computer bits, but there are ways to mitigate that and still use PCI-e, such as using a case design that ensures the RF side is well shielded. The design could also be broken into two parts with the ADC/DAC/Clocks isolated and connected to the FPGA on a PCI-e card by means of line driver ICs and off-the-shelf cables. Any thoughts from those more involved with the software or hardware design? 73, John KF5SAB On Fri, Aug 22, 2014 at 10:31 PM, Phil Harman wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Marc, > > Thanks for your email. > > We still have a way to go with fully proving the DFC idea but so far its looking good. > > We actually had this discussion a few minutes ago during the weekly Teamspeak session. > > Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. > > What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. > > What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. > > With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. > > If such a PCB design is of interest to you then please lets discuss further. > > 73 Phil....VK6PH > > > -----Original Message----- From: Marc Lalonde > Sent: Saturday, August 23, 2014 10:31 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > guess some one already work on a ADC /DAC Board that go on the > expansion connector of the DEV kit ? > seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA > as Glue logic.. > > that may remove the LAN / PHY from equation and permit made nice self > contained platform ;-) > > if no one yet ,i may willing to help work on this ,i was a senior > PCB designer whit some design backgrond .. > > Best 73! > Marc VE2OLM _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1409070984.0 From k5so at valornet.com Tue Aug 26 09:38:47 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Tue, 26 Aug 2014 10:38:47 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <3AD73732-607A-4AB5-96C3-5B78FB0B1477@valornet.com> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> <3AD73732-607A-4AB5-96C3-5B78FB0B1477@valornet.com> Message-ID: > ... will work fine with either a single powerful computer (SBC) connected to the hardware OR with a high performance computer connected to the hardware as we have traditionally done. I meant: single board computer (SBC). 73, Joe K5SO On Aug 26, 2014, at 10:35 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi John, > > I completely agree with your analysis and have in fact privately expressed to several people my concern regarding use of a (marginally powerful) single board computer in the mix. But keep in mind that the new protocol that Phil is contemplating will work fine with either a single powerful computer (SBC) connected to the hardware OR with a high performance computer connected to the hardware as we have traditionally done. > > Therefore the SBC development activity underway doesn?t limit things at all for those of us who would prefer to use a single high performance computer instead. Users of a single high performance computer can still exploit the new protocol and realize the same flexibility and performance benefits that Phil mentioned that are associated with the new proposed ethernet protocol. > > The Jetson board SBC approach is simply an activity that is running in parallel with the original architecture scheme. Whether you wish to use an SBC configuration or not is entirely optional and open to your personal preference. I?ve come to realize that we?re not losing anything at all by having some people working on SBC configurations in order to have low-performance hand held devices able to interface the hardware (if that happens to be your personal interest). > > 73, Joe K5SO > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlalonde at alphatronique.com Tue Aug 26 09:43:08 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Tue, 26 Aug 2014 12:43:08 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <53FCB91C.1090209@alphatronique.com> HI mini-PCI-e may put on PCI-e whit common adapter ,then put on standard PC if need or may use PCI-e to PCI-e backplane + CPU of some sort ,so many possibility it need at last 2 lane for a decent SDR (make cation whit Bit Vs Byte) ADC was 12 Bit x 122Mhx and DAC was 14 bit x 122Mhz this may also double in future... so ~ 3.2Gbit/s integrating NVidia silicon onto an HPSDR ,not a thing that i doable at decent cost Best 73! Marc L. VE2OLM On 26/08/2014 11:08 AM, John Laur wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Ideas for discussion: > > First, isn't this similar to the architecture that has been > implemented by PA3FWM's wideband websdr for some time? > ADC->FPGA->Ethernet->FFT with GPU and then individual receivers only > have to grab the bins and do an IFFT? If so, it's a clear winner as > far as scaling the capabilities go. I am very excited to see the > excitement for it. But I am concerned with the discussion dwelling > around the Jetson board as being central and essential to this > architecture long-term although I do think it is valuable as a > motivator. > > For a hardware architecture that will hang around for a while and be > the most compatible, I would like to discuss the option of designing > instead for regular (non-mini) PCI-e. > > While it's great to have these 'fun-size' SBC's there is really > nothing that I have seen to conclude that NVidia or a 3rd party will > continue to ship such a thing as a developer or retail product with > extremely similar architecture and form factor over the long term. So > unless there is someone who wants to keep up with the hassle of > actually integrating NVidia silicon onto an HPSDR board and making a > wholly integrated system a la the Flex-6k, I do not think it is worth > exploring too far into that paradigm. Designing for the Jetson's > mini-pcie interface would severely limit future flexibility should the > product be dropped and limit the use of the HPSDR hardware in cases > where mini-pcie is not available on a board with a suitable CUDA GPU. > Plus, Jetson itself has a huge disadvantage (for the HPSDR server > application) of having only a single Ethernet interface. I understand > that there is still 16Mbps of bandwidth 'left over' (and that the > interface itself is full duplex) but that is an awfully limiting > margin considering the possibilities that exist with the architecture. > Yes; one could be added on USB without occupying the mini-PCIe, but at > the expense of the limited CPU resources. Running ethernet interfaces > at 99% capacity is a tricky business anyway. It would be nice to > simply eliminate that challenge. > > There is one thing we can be sure of though: NVidia will continue to > ship regular PCI-e graphics cards for the foreseeable future. > Depending on the version of CUDA required, an inexpensive NVidia > GeForce card will likely exceed Jetson's performance by quite a lot. A > small dedicated system with dual PCIe slots and a GPU can be designed > and built with specifications exceeding those of the Jetson board at > similar cost, and the same architecture can be implemented. I do not > see that the Jetson has any advantage over such system other than > perhaps power consumption or having fixed design. The problem of power > consumption is likely not to be a large concern in this application, > and the second problem can be eliminated by specifying a tested > reference design. > > * PCI-e is the fastest common interface available. Current standards > take speeds to 250gbps (PCI-e 4.0 x16), and even the lowest common > denominator (PCI-e 1.0 1x) is still 2gbps. > > * PCI-e can be bridged to Mini-PCIe, Thunderbolt, or Expresscard > interfaces with off-the-shelf hardware. > > * PCI-e supports DMA, RDMA, and peer to peer data transfer. Data can > be moved from HPDSR to GPU without involving the CPU. A passive PCI-e > backplane could be used as a future replacement for Atlas with the > ability to use off the shelf parts. > > * PCI-e is easy to interface in the modern Altera FPGAs with hardware > controllers and does not require the difficult task of writing IP for > 3rd party interface chips (Existing IP for things like USB 3.0 > controllers and 10gbE chips are licensed and generally not compatible > with open-source licenses. I believe this is one of the major pain > points with the current HPSDR FPGA efforts.) > > * PCI-e is generally backwards (and forwards!) compatible. So modern > high-bandwidth hardware can be designed and still used with older or > less powerful hosts. > > An external interface of some sort has the advantage that the RF bits > can be somewhat isolated from the noisy computer bits, but there are > ways to mitigate that and still use PCI-e, such as using a case design > that ensures the RF side is well shielded. The design could also be > broken into two parts with the ADC/DAC/Clocks isolated and connected > to the FPGA on a PCI-e card by means of line driver ICs and > off-the-shelf cables. > > Any thoughts from those more involved with the software or hardware design? > > 73, John KF5SAB > > > On Fri, Aug 22, 2014 at 10:31 PM, Phil Harman wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Marc, >> >> Thanks for your email. >> >> We still have a way to go with fully proving the DFC idea but so far its looking good. >> >> We actually had this discussion a few minutes ago during the weekly Teamspeak session. >> >> Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. >> >> What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. >> >> What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. >> >> With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. >> >> If such a PCB design is of interest to you then please lets discuss further. >> >> 73 Phil....VK6PH >> >> >> -----Original Message----- From: Marc Lalonde >> Sent: Saturday, August 23, 2014 10:31 AM >> To: hpsdr at lists.openhpsdr.org >> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >> >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi >> >> guess some one already work on a ADC /DAC Board that go on the expansion >> connector of the DEV kit ? >> seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA >> as Glue logic.. >> >> that may remove the LAN / PHY from equation and permit made nice self >> contained platform ;-) >> >> if no one yet ,i may willing to help work on this ,i was a senior PCB >> designer whit some design backgrond .. >> >> Best 73! >> Marc VE2OLM > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1409071388.0 From hvh.net at gmail.com Tue Aug 26 10:40:02 2014 From: hvh.net at gmail.com (Hermann) Date: Tue, 26 Aug 2014 19:40:02 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: Dear John, all, thank you all for your thoughts. Here's my 2-cent: the discussion focus too much on Hardware, and the Jetson board is surely an experimental platform. It doesn't makes much sense to ponder upon if this board has one or two ethernet interfaces. Of course, this does matter if a certain architecture should be tested. Btw, the upcoming Tablets and Handhelds will have chips like the Tegra K1, and in a couple of years even more powerful devices. So, we will indeed have handhelds with super-computing power - at least in a certain sense. Hardware is subject to fast changes, but how do we keep up with the Software? Why do you think is Altera, e.g., providing an interface to OpenCL? Nvidia is doing a really great job in providing not only fast hardware, but also a complete programming model, together with all necessary tools. In a completely different domain (but also embedded), chip providers are building great hardware, with 6 or more cores etc etc., but don't tell the software architects how to program these fine controllers, or how to migrate software, which grew out of 20 years of development (and as such is invaluable). The 'multicore problem' is still not solved (some may claim they have), and the majority of algorithms and code (with some very few exceptions, like FFTs, or matrix multiplication) is NOT easily parallelized. Why does nobody (with very few but remarkable exceptions) take existing code (KISS Console, PowerSDR, cuSDR) and work on it to implement this or that feature? I receive so many emails and comments on the mailing lists, asking for new features. And if it's not going fast enough, people start declaring cuSDR as vaporware, hi. It is not much more difficult, than, as Joe, K5SO has reported so wonderful, start working on code for FPGAs. Hardware changes fast, Software not. The idea of open source is not only that the software is free. Much more important is that a lot of people start contributing to it. For me this is the main message from Phil's original post. 73, Hermann DL3HVH -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcrewson at cinci.rr.com Tue Aug 26 11:45:42 2014 From: rcrewson at cinci.rr.com (Rob Crewson) Date: Tue, 26 Aug 2014 14:45:42 -0400 Subject: [hpsdr] 'Cuda 6.5 Features and OverView'. Message-ID: <000c01cfc15d$f0843830$d18ca890$@cinci.rr.com> To anyone interested in this topic. I just watched a webinar from NVidia on their recent release of Cuda 6.5 -> 'Cuda 6.5 Features and OverView'. I took screenshots of the presentation slides (14) . The last one is of the chat board questions, one which pertained to the 'Jetson tk1' board. If you want a copy of either email me off list @ rcrewson at cinci.rr.com . 73, RobC VE3EW -------------- next part -------------- An HTML attachment was scrubbed... URL: From jra at febo.com Tue Aug 26 12:16:43 2014 From: jra at febo.com (John Ackermann N8UR) Date: Tue, 26 Aug 2014 15:16:43 -0400 Subject: [hpsdr] External T/R switch for PureSignal Message-ID: <53FCDD1B.5010803@febo.com> If you're interested in a kit to provide external T/R switching optimized for PureSignal setups, read on. If you've experimented with PureSignal, you know that the ANAN T/R switching isn't up to the task because (a) it shorts the receiver input to ground during TX, and (b) there is a lot of crosstalk within the switch/filter board. The combination means that you can't get a useful sampler signal into the radio without some sort of modification. Thanks to much help from KC9XG, I found that it's easy on the ANAN-10 to bypass the internal T/R by just removing the RX coax between the Hermes board and the amp board. Then, you can use the Hermes SMA RX connector and get TX from the ANT1 BNC connector. After that, all you need is an external switch. No new holes are required. (I don't own an ANAN-100 but as long as you can route the RX signal directly to the Hermes receive input, the same setup should work.) The external switch needs two relays: one to switch the antenna between TX and RX, and the second to switch the receiver path between antenna on RX and a signal sampler on TX. It needs good isolation for PureSignal (which is where my perfboard prototype with junkbox relays fell short). So, I've laid out a 3 inch (wide) by 1 inch (deep) circuit board with two BNC connectors (ANT and TX) and two SMA connectors (RX and SAMPLE). It uses the same relays as the Alex boards, and theoretically should have more than enough isolation for PureSignal. It should handle 100W. It takes 12V input and has a transistor switch for keying. This is early stage, and I'm just ordering Rev. A boards now. But I'm trying to see if there's enough interest to do a TAPR kit (all through-hole parts!) that would probably be in the $50 range. If you'd be interested, please drop a note off-list to jra at febo.com. 73, John 1409080603.0 From jbden at charter.net Tue Aug 26 12:47:31 2014 From: jbden at charter.net (John) Date: Tue, 26 Aug 2014 14:47:31 -0500 Subject: [hpsdr] AsRock SBC Message-ID: <53FCE453.8030503@charter.net> If some one is looking for a nice SBC, check out AsRock's line of j1900 mini-itx motherboards. I just buit one using memory and case I had on hand, for less than $200. It has built in dc-dc converter so it will use a netbook brick for power. Only uses about 10 Watts. Soon after I built it, they announced a new one using j2900 intel Pentium. I am not going to list all features, because they are on Asrock's site. John N4HXL 1409082451.0 From k5so at valornet.com Tue Aug 26 12:59:31 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Tue, 26 Aug 2014 13:59:31 -0600 Subject: [hpsdr] Timing Closure Field Guide Message-ID: All, In an effort to assist in making the timing closure tasks associated with OpenHPSDR firmware development less intimidating and easier for beginners to participate I have prepared a PDF document that describes a standardized procedure that I use for the task. The document may be downloaded from http://www.k5so.com/TimingClosureFieldGuide.pdf Please be aware that I do not claim to be an expert in this area and that the document may well have some errors and omissions; but I can guarantee that the document contains a decent sampling of the author?s personal bias. 73, Joe K5SO -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnlaur at gmail.com Tue Aug 26 13:27:22 2014 From: johnlaur at gmail.com (John Laur) Date: Tue, 26 Aug 2014 15:27:22 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53FCB91C.1090209@alphatronique.com> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> <53FCB91C.1090209@alphatronique.com> Message-ID: All, Thank you for the good discussion. My intention was not to focus too much on the Jetson discussion actually; I do know that if the code runs on Jetson I can happily build a small linux machine that will also run it, so nobody is "locking" anyone into any particular thing. I just think the Jetson is a low mark to aim for. If it can do a realtime 30mHz FFT, so can basically any current GPU. Even low power cards like the GeForce 750 Ti will run circles around it, while drawing 60W and costing less. I think anyone who has ever compiled up the fosphor plugin on GNU Radio has probably lamented not having that view available all the time. So I wont beat on Jetson any more. I just thought while we were on the subject of architectures it would be a good time to cut to the chase on the bandwidth problem. While I will agree with Hermann that SDR hardware (and the HDL features of HPSDR) seem to be changing as fast or faster than SDR software in recent months, I also think it ought to be the other way around. On the big list of SDR's from Wikipedia http://en.wikipedia.org/wiki/List_of_software-defined_radios I note only 2 devices use PCIe. I think the hardware is changing largely because of all the ways that developers are choosing to deal with the problems of interface constraints; hardware that can filter this amount of data at this datarate is neither easy nor cheap to engineer. There is no need to go to this length if you can just move all the data in the first place. But if the GPU architecture is the way forward, it's just silly to put an intermediate interface that requires a lot of HDL work in the way. For a direct sampling design the most future proof design possible is to make sure the hardware is at minimum capable of sending the raw ADC/DAC/Clock data in and out at full datarate to an attached device. IMO the reason working with the SoCKit hardware and Scotty's boards is probably so nice is because the interface from the FPGA to the software is basically transparent. (This is half speculation as I have a SoCKit that I have used quite a bit but have not yet put funds together for a board set from Scotty) There is no ethernet PHY and framing and protocol to get at the DDC data; the CPU just opens a device and starts reading. If That eliminates a lot of complexity. But you could easily plug his board set into a different dev kit like this http://www.altera.com/products/devkits/altera/kit-cyclone-v-gt.html and with some (admitted) effort you could make yourself a prototype PCIe HPSDR card right now that could do DMA transfers of ADC samples right into GPU memory with the same sort of ease. This is the beauty of a high speed interconnect standard. In this case it is HSMC, useful only within a certain scope, but it makes the point I think. A comment for Marc: From what I have seen Mini-PCIe is generally only ever offered with a x1 interface with the exception of MXM, so it makes more sense to adapt a PCIe card to the mini-PCIe form factor than vice versa; that way the card can be designed as a 4x or such. (It can always be allowed to fall back to 1x) Anyway to sum it all up neatly, a single integrated board like Hermes with a Cyclone V SoC part on board that can be used standalone or plugged in and used as a PCIe card would be pretty attractive HPSDR platform, I gotta say. 73, John KF5SAB 1409084842.0 From rcrewson at cinci.rr.com Tue Aug 26 15:21:16 2014 From: rcrewson at cinci.rr.com (Rob Crewson) Date: Tue, 26 Aug 2014 18:21:16 -0400 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: <001501cfc17c$0e1ef8d0$2a5cea70$@cinci.rr.com> Excellent document Joe, short , single path , to the point. I've nodded off many time trying to get thru the Altera docs. 73, RobC - VE3EW -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Joe Martin K5SO Sent: Tuesday, August 26, 2014 4:00 PM To: HPSDR list Subject: [hpsdr] Timing Closure Field Guide ***** High Performance Software Defined Radio Discussion List ***** 1409091676.0 From n9vv at wowway.com Tue Aug 26 15:27:06 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Tue, 26 Aug 2014 17:27:06 -0500 Subject: [hpsdr] AsRock SBC In-Reply-To: <53FCE453.8030503@charter.net> References: <53FCE453.8030503@charter.net> Message-ID: <53FD09BA.30505@wowway.com> Hi John, I also like to point my Update Scanner (checks webpages for chances every day) at this website: http://linuxgizmos.com/category/boards/ LinuxGizmos seems to have quite a wide variety of SBC's listed and updated on an almost hourly basis all the best, 73 de Ken N9VV On 8/26/2014 2:47 PM, John wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > If some one is looking for a nice SBC, check out AsRock's line of j1900 > mini-itx motherboards. > I just buit one using memory and case I had on hand, for less than $200. > It has built in dc-dc converter so it will use a netbook brick for > power. Only uses about 10 Watts. Soon after I built it, they announced a > new one using j2900 intel Pentium. I am not going to list all features, > because they are on Asrock's site. > John N4HXL > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1409092026.0 From scotty at tonks.com Tue Aug 26 16:56:21 2014 From: scotty at tonks.com (Scott Cowling) Date: Tue, 26 Aug 2014 16:56:21 -0700 Subject: [hpsdr] Liva PC on sale at Newegg In-Reply-To: <53FCE453.8030503@charter.net> References: <53FCE453.8030503@charter.net> Message-ID: <7.0.1.0.2.20140826164456.0b4a5008@tonks.com> Hi all, Just saw this on the Newegg site (thanks to Ken, N9VV) and it looks very interesting. http://www.newegg.com/Product/Product.aspx?Item=N82E16856501007 While I have my share of low-power (and low-capability) PCs, this one looks especially intriguing. At only $132 including 2GB of RAM and 32GB eMMC drive, it is about as cheap as they come. Conduction cooled, Gigabit Ethernet, b/g/n WiFi, Bluetooth, dual monitor (HDMI + VGA) support, two USB ports (one 2.0, one 3.0) and a case; what more could you ask for? The special is only good through the end of August, so take a quick look if you are in the market for a new radio toy. Mine arrives Thursday. :-) We'll see if it has the guts to run GHPSDR3-Alex to put an HF1 receiver up on the QtRadio network! 73, Scotty WA2DFI 1409097381.0 From wb9qzb_groups at yahoo.com Tue Aug 26 17:29:19 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Tue, 26 Aug 2014 17:29:19 -0700 Subject: [hpsdr] Summer 2014 TAPR PSR Digital Communications Journal Available In-Reply-To: <1409098446.44945.YahooMailNeo@web140204.mail.bf1.yahoo.com> References: <1409098446.44945.YahooMailNeo@web140204.mail.bf1.yahoo.com> Message-ID: <1409099359.74958.YahooMailNeo@web140203.mail.bf1.yahoo.com> Summer 2014? TAPR PSR Digital Communications Journal? Available http://www.tapr.org/psr/psr126.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian13434 at yahoo.co.uk Wed Aug 27 02:23:23 2014 From: brian13434 at yahoo.co.uk (Brian D) Date: Wed, 27 Aug 2014 10:23:23 +0100 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: I've reverted to 4.1 firmware. The NaN problem has disappeared so it looks as if the angelia 4.2 firmware is the problem. Jae Stutzman wrote: I should have mentioned that I recently upgraded to 4.2 Angelia as well. So it could be either. I'll try downgrading back to 4.1 to see if that changes anything. I noticed it with TUN and it was reading out about 85W for each band. I was originally trying to find out if I was affected by the 10M winding issue. On Tue, Aug 26, 2014 at 4:54 AM, Brian D wrote: ***** High Performance Software Defined Radio Discussion List ***** Jae Stutzman wrote: > Is it just me or does the fwd pwr TX meter seem to be to be reading lower > than it should with this release? I was checking power outputs and it > seems to be about 15 watts lower than reality. Is this just me? I was > trying to adjust output power and that's when I realized it. I reset > databases just to be sure. I didn't notice this on 3.2.17. I haven't noticed it reading low but I've had several times it reading NaN for VSWR when tuning into the goood match of my test load. Not sure at this stage if it is the new version of HPSDR or my recent firmware upgrade to 4.2 (angelia). -- Brian D G3VGZ -- Brian D G3VGZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1409131403.0 From k5so at valornet.com Wed Aug 27 06:10:22 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Wed, 27 Aug 2014 07:10:22 -0600 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: There are unfortunately subtle physical differences board-to-board and chip-to-chip on all of the hardware we use. These differences can sometimes result in different behavior of firmware on some boards. There are no features coded differently in the firmware versions mentioned. Minor signal-path timing differences between v4.1 and v4.2 are all that distinguish the two versions, in this particular case. If an earlier version of firmware works better for your particular board than does a later version then by all means use what works for you. 73, Joe K5SO On Aug 27, 2014, at 3:23 AM, Brian D wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I've reverted to 4.1 firmware. The NaN problem has disappeared so it looks > as if the angelia 4.2 firmware is the problem. > > > Jae Stutzman wrote: > I should have mentioned that I recently upgraded to 4.2 Angelia as well. So > it could be either. I'll try downgrading back to 4.1 to see if that changes > anything. I noticed it with TUN and it was reading out about 85W for each > band. I was originally trying to find out if I was affected by the 10M > winding issue. > > > On Tue, Aug 26, 2014 at 4:54 AM, Brian D wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Jae Stutzman wrote: > >> Is it just me or does the fwd pwr TX meter seem to be to be reading lower >> than it should with this release? I was checking power outputs and it >> seems to be about 15 watts lower than reality. Is this just me? I was >> trying to adjust output power and that's when I realized it. I reset >> databases just to be sure. I didn't notice this on 3.2.17. > > I haven't noticed it reading low but I've had several times it reading NaN > for VSWR when tuning into the goood match of my test load. Not sure at this > stage if it is the new version of HPSDR or my recent firmware upgrade to 4.2 > (angelia). > > > -- > Brian D > G3VGZ > 1409145022.0 From ad0es at ad0es.net Wed Aug 27 07:19:06 2014 From: ad0es at ad0es.net (AD0ES) Date: Wed, 27 Aug 2014 08:19:06 -0600 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: Hi, I have been slowly dipping my toes into the SDR pool, have a mercury rcvr setup functioning now. Excited about the direction new development is taking, especially in the area of moving more of the work from FPGA to a general class cpu/gpu. Next step for me is to setup with the tools necessary to write FPGA/gpu/openCL code. I spent some time on the Altera(?) site and went away totally confused. Are there tools available allowing one to design/write/compile FPGA code for these beasts without paying license fees or BEING CONNECTED to the net while using? I have no internet access at home and need a non-inet solution. If someone could provide a cookbook list of where/how to get the tools I believe it would get more people started down this path. tia, Steve AD0ES On Aug 26, 2014, at 1:59 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > In an effort to assist in making the timing closure tasks associated with OpenHPSDR firmware development less intimidating and easier for beginners to participate I have prepared a PDF document that describes a standardized procedure that I use for the task. The document may be downloaded from 1409149146.0 From k5so at valornet.com Wed Aug 27 07:51:49 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Wed, 27 Aug 2014 08:51:49 -0600 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: <8D51197B-0E5F-4B20-86A6-AB8D93FB0713@valornet.com> Hi Steve, With regard to the necessary FGPA tools, you need only the free Quartus II program download from: https://www.altera.com/download/sw/dnl-sw-index.jsp at the bottom of the page is a window that allows you to select to download any version of Quartus II from v2.2 to v14.0. As you are working with Atlas-based boards I would suggest that the latest version for you work with should be v13.0 as later versions do not support the Cyclone II FPGA used in Penelope and the latest v14.0 does not support the Cyclone III FPGA used in Mercury. Quartus II will run just fine without being connect to the internet. You will receive a startup message that Quartus II can?t get to the Quartus website to check for updates but simply close the window and things will be fine. 73, Joe K5SO On Aug 27, 2014, at 8:19 AM, AD0ES wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi, > > I have been slowly dipping my toes into the SDR pool, have a mercury rcvr setup functioning now. Excited about the > direction new development is taking, especially in the area of moving more of the work from FPGA to a general class > cpu/gpu. Next step for me is to setup with the tools necessary to write FPGA/gpu/openCL code. > > I spent some time on the Altera(?) site and went away totally confused. Are there tools available allowing one to > design/write/compile FPGA code for these beasts without paying license fees or BEING CONNECTED to the net while using? > I have no internet access at home and need a non-inet solution. > > If someone could provide a cookbook list of where/how to get the tools I believe it would get more people started down > this path. > > tia, > Steve AD0ES > 1409151109.0 From wb9qzb_groups at yahoo.com Wed Aug 27 07:47:34 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Wed, 27 Aug 2014 07:47:34 -0700 Subject: [hpsdr] DCC Proceedings Abstracts Announced - 2014 ARRL/TAPR Digital Communications Conference Austin, TX September 5-7, 2014 In-Reply-To: <1409150515.91658.YahooMailNeo@web140204.mail.bf1.yahoo.com> References: <1409150515.91658.YahooMailNeo@web140204.mail.bf1.yahoo.com> Message-ID: <1409150854.72388.YahooMailNeo@web140201.mail.bf1.yahoo.com> http://www.tapr.org/pub_dcc33.html DCC Proceedings Abstracts: 33rd ARRL and TAPR Digital Communications Conference September 5-7, 2014 ________________________________ High-Speed Wireless Networking in the UHF and Microwave Bands? by?David Bern, W2LNX?and?Keith Elkin, KB3TCB Abstract:?This paper discusses building an amateur radio wireless network using commercial off the shelf wireless networking equipment that is currently available. As an example, four Ubiquiti NanoStation M3 3.4 GHz digital radios are used to assemble a demonstration network of two wireless network links that operate on two different frequencies. In conclusion, the paper invites the amateur radio community to build a nationwide highspeed amateur radio wireless backbone network to connect all local amateur radio area community wireless networks. Proceedings Paper Clarifying the Amateur Bell 202 Modem? by?Kenneth W. Finnegan, W6KWF?and?Bridget Benson, PhD The Stream Control Transmission Protocol (SCTP) and Its Potential for Amateur Radio? by?Eduardo Gonzalez?,?Dr Stan McClellan?and?Dr Wuxu Peng SDR-based DATV-Express Exciter for Digital-ATV? by?Ken Konechy, W6HHC A Radioteletype Over-Sampling Software Decoder for Amateur Radio? by?Joseph J. Roby, Jr, K0JJR An HF Frequency-Division Multiplex (FDM) Modem? by?Steven Sampson, K5OKC Modulation - Demodulation Software Radio? by?Alex Schwarz VE7DXW?and?Guy Roels ON6MU Installing a LIF port into the FT-950 transceiver? by?Alex Schwarz, VE7DXW Installing a LIF port into the IC-756ProIII transceiver? by?Alex Schwarz, VE7DXW The European HAMNET - A Large Scale High Speed Radio Network? by?Jann Traschewski, DG8NGN Implementation of Basic Analog and Digital Modulation Schemes using a SDR Platform? by?Jose M. Valencia?and?Omar H. Longoria -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjablonski at att.net Wed Aug 27 11:06:22 2014 From: bjablonski at att.net (Barry Jablonski) Date: Wed, 27 Aug 2014 14:06:22 -0400 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: <53FE1E1E.6050304@att.net> Hi Steve. Here is a link to a PDF of Altera's "Intro to Quartus II": www.altera.com/literature/manual/intro_to_quartus2.pdf Hope it helps. Barry WB2ZXJ 1409162782.0 From scotty at tonks.com Thu Aug 28 13:43:06 2014 From: scotty at tonks.com (Scott Cowling) Date: Thu, 28 Aug 2014 13:43:06 -0700 Subject: [hpsdr] Success with GNURadio on LIVA PC! In-Reply-To: <53FE1E1E.6050304@att.net> References: <53FE1E1E.6050304@att.net> Message-ID: <7.0.1.0.2.20140828130549.056c7120@tonks.com> Hi all, This is not strictly HPSDR related, but I thought that most would be interested is the SDR capabilities of the ECS LIVA PC that is on sale at Newegg for $132 through Friday. I got the LIVA on Wednesday and assembled it. (Be careful with those little MMCX connectors for the WiFi antenna. I broke one of them and had to repair it, which was not fun.) I installed Ubuntu 14.04 from a USB flash drive, then downloaded and ran the GNURadio install script for version 3.7.4. Then I downloaded the SDRstick source block and followed the instructions to build and install it (only about 6 steps). I plugged in my HF1 and BeMicroSDK hardware to the USB port (for power) and the GigE port (for data). Amazingly, it came right up! The sample AM receiver flowgraph works, and at 384K bandwidth I can hear (and see) AM broadcast stations with no dropouts. This is pretty exciting for such a small, low-power PC! When I go to 1.25MHz bandwidth, the receiver still works, but the PC just can't keep the graphics on the screen updated. I haven't tweaked any priorities yet, but it looks like 1.25MHz is a bit too much for this "little PC that could"! I will bring this setup to DCC next weekend to demo. 73, Scotty WA2DFI 1409258586.0 From g4hup at btinternet.com Thu Aug 28 15:01:06 2014 From: g4hup at btinternet.com (dave powis) Date: Thu, 28 Aug 2014 23:01:06 +0100 Subject: [hpsdr] FS - Hermes set-up Message-ID: <1409263266.99171.YahooMailNeo@web87703.mail.ir2.yahoo.com> For sale - my Hermes set up, comprising: TAPR Hermes mounted in Hammond case, with additional chip heatsink and external power connector N8UR breakout board for J16 Munin PA kit with heatsink and Hammond case (not assembled). Looking for ?800.? Shipping to be discussed - preference to UK sale. Also available Alex Tx/Rx Filter set in housing? - assembled, with cables Looking for ?300. Shipping to be discussed - preference to UK sale. Please contact me off-list at g4hup-at-btinternet-dot-com Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From lstoskopf at cox.net Thu Aug 28 21:05:17 2014 From: lstoskopf at cox.net (lstoskopf at cox.net) Date: Fri, 29 Aug 2014 0:05:17 -0400 Subject: [hpsdr] Success with GNURadio on LIVA PC! In-Reply-To: Message-ID: <20140829000517.QTPFP.168732.imail@eastrmwml107> Great. Some of us did the Kickstarter thing to have the talks put on HamTV (I think). Hit him up for a quick segment on your setup and operation. Awaiting the new AC9 board. N0UU 1409285117.0 From jkelly at verizon.net Fri Aug 29 03:07:06 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 29 Aug 2014 06:07:06 -0400 Subject: [hpsdr] WTB Funcube Dongle Pro Message-ID: <0NB2007XYC3WYBA0@vms173015.mailsrvcs.net> U2VuZCBlbWFpbCB0bzoKCksyU0RSIGF0IHZlcml6b24ubmV0CgpKZWZm 1409306826.0 From wb9qzb_groups at yahoo.com Fri Aug 29 12:30:21 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Fri, 29 Aug 2014 12:30:21 -0700 Subject: [hpsdr] ARRL/TAPR DCC Speaker Schedule Announced, Austin, TX, 9/5 - 9/7/14 (Walk-In Registrations at DCC Welcome) In-Reply-To: <8D191D64470CED4-1EF4-448A@webmail-vd010.sysops.aol.com> References: <1409340051.42235.YahooMailNeo@web140202.mail.bf1.yahoo.com> <8D191D5E158017D-1EF4-443D@webmail-vd010.sysops.aol.com> <8D191D64470CED4-1EF4-448A@webmail-vd010.sysops.aol.com> Message-ID: <1409340621.78960.YahooMailNeo@web140201.mail.bf1.yahoo.com> DCC Speaker Schedule Announced 2014 ARRL/TAPR Digital Communications Conference Austin, TX September 5 - 7, 2014 http://www.tapr.org/pdf/DCC_2014_Schedule_2014-08-27.pdf Register for the DCC Walk-in registrations at DCC are very welcome. Online Registration Form https://www.tapr.org/dccregistration.php Pre-registration will close on August 30th to allow the office staff to complete preparations (print badges and stuff envelopes) and travel to the conference. Use of the on-line registration form after August 30th is encouraged, as it will save time at the registration desk filling in hard copy forms and wait for credit card processing.. Tucson Amateur Packet Radio Phone: (972) 671-TAPR (8277) Contact TAPR Office: http://www.tapr.org/inforequest.php -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkelly at verizon.net Fri Aug 29 15:17:12 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 29 Aug 2014 18:17:12 -0400 Subject: [hpsdr] WTB Funcube Dongle Pro In-Reply-To: <0NB2007XYC3WYBA0@vms173015.mailsrvcs.net> References: <0NB2007XYC3WYBA0@vms173015.mailsrvcs.net> Message-ID: <594C7EC51FA641619B6FBBD3FBAEFBAE@JeffPC> Thank you got one. Jeff -----Original Message----- From: Jeff Kelly Sent: Friday, August 29, 2014 6:07 To: hpsdr at openhpsdr.org Subject: [hpsdr] WTB Funcube Dongle Pro ***** High Performance Software Defined Radio Discussion List ***** Send email to: K2SDR at verizon.net Jeff _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1409350632.0 From w5wc at windstream.net Fri Aug 29 16:54:12 2014 From: w5wc at windstream.net (Doug Wigley) Date: Fri, 29 Aug 2014 18:54:12 -0500 Subject: [hpsdr] PowerSDR/OpenHPSDR mRX PS v3.2.19 released Message-ID: <00ad01cfc3e4$88b755f0$9a2601d0$@net> All, PowerSDR/OpenHPSDR mRX PS v3.2.19 has been released. Bug fixes added for the following problems: - APF text field in the VFOA window masked part of the VHF frequency. - Unable to use the DJ Console with CTUN enabled. Added colors to the diversity "Enable" button. Green = ON, Red = OFF. No database reset required! This release can be downloaded from the openhpsdr.org website. http://openhpsdr.org/download.php 73, Doug W5WC 1409356452.0 From mlalonde at alphatronique.com Fri Aug 29 17:29:08 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Fri, 29 Aug 2014 20:29:08 -0400 Subject: [hpsdr] Success with GNURadio on LIVA PC! In-Reply-To: <7.0.1.0.2.20140828161242.05444838@tonks.com> References: <53FE1E1E.6050304@att.net> <7.0.1.0.2.20140828130549.056c7120@tonks.com> <53FFA0FB.2090201@alphatronique.com> <7.0.1.0.2.20140828161242.05444838@tonks.com> Message-ID: <54011AD4.2080806@alphatronique.com> Hi first that really small PC ! next it require a "UEFI" bootable USB key AND a 64Bit win 8.1 for work anything else fail to boot and/or install ,i lost big part of my day figure it ... i make work whit decent performance of 2 or less decoding WSJT-X (not forget the NTP server) JT65HF-109 one that not work JT65-HF HB9HQX remain on "receiving" so whit my KX3 i made nice portable JT65 setup and\or monitor for 6M opening 73 .. Marc L VE2OLM On 28/08/2014 7:13 PM, Scott Cowling wrote: > Hi Marc, > > Sounds like a good use for one! I would like to hear about your setup > when you get it running. > > 73, > Scotty WA2DFI > > At 17:36 2014-08-28 -0400, you wrote: >> Hi >> >> Thank i have order one for try to use it for monitor 6M Band opening >> whit JT65A >> >> 73 >> Marc VE2OLM >> >> On 28/08/2014 4:43 PM, Scott Cowling wrote: >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> Hi all, >>> >>> This is not strictly HPSDR related, but I thought that most would be >>> interested is the SDR capabilities of the ECS LIVA PC that is on >>> sale at Newegg for $132 through Friday. >>> >>> I got the LIVA on Wednesday and assembled it. (Be careful with those >>> little MMCX connectors for the WiFi antenna. I broke one of them and >>> had to repair it, which was not fun.) >>> >>> I installed Ubuntu 14.04 from a USB flash drive, then downloaded and >>> ran the GNURadio install script for version 3.7.4. Then I downloaded >>> the SDRstick source block and followed the instructions to build and >>> install it (only about 6 steps). >>> >>> I plugged in my HF1 and BeMicroSDK hardware to the USB port (for >>> power) and the GigE port (for data). >>> >>> Amazingly, it came right up! The sample AM receiver flowgraph works, >>> and at 384K bandwidth I can hear (and see) AM broadcast stations >>> with no dropouts. This is pretty exciting for such a small, >>> low-power PC! >>> >>> When I go to 1.25MHz bandwidth, the receiver still works, but the PC >>> just can't keep the graphics on the screen updated. I haven't >>> tweaked any priorities yet, but it looks like 1.25MHz is a bit too >>> much for this "little PC that could"! >>> >>> I will bring this setup to DCC next weekend to demo. >>> >>> 73, >>> Scotty WA2DFI >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: >>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > 1409358548.0 From aa8k73 at gmail.com Fri Aug 29 19:31:47 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 29 Aug 2014 22:31:47 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/30 Message-ID: <54013793.3030108@gmail.com> The 30/Aug TeamSpeak mp3 (67 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3513 > or < http://www.hamsdr.com/dnld.aspx > Only silence truncation editing was done on this recording. 1409365907.0 From dc6ny at gmx.de Sun Aug 31 02:49:41 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Sun, 31 Aug 2014 11:49:41 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> <53FCB91C.1090209@alphatronique.com> Message-ID: <000001cfc500$e38379b0$aa8a6d10$@de> Hi, I read a topical notification of the USB Promoter Group (HP, Intel, MS, Renesas Elec, TI ) that USB 3.1 will be already available end of 2014. This smart (cheap) interface could be one option for a fast 10 Gbit/s connection of future broadband DDC/DUC hardware and versatile computer architectures. I think it's certainly worth to watch further progress and market. 73, Helmut, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von John Laur Gesendet: Dienstag, 26. August 2014 22:27 An: HPSDR list Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** All, Thank you for the good discussion. My intention was not to focus too much on the Jetson discussion actually; I do know that if the code runs on Jetson I can happily build a small linux machine that will also run it, so nobody is "locking" anyone into any particular thing. I just think the Jetson is a low mark to aim for. If it can do a realtime 30mHz FFT, so can basically any current GPU. Even low power cards like the GeForce 750 Ti will run circles around it, while drawing 60W and costing less. I think anyone who has ever compiled up the fosphor plugin on GNU Radio has probably lamented not having that view available all the time. So I wont beat on Jetson any more. I just thought while we were on the subject of architectures it would be a good time to cut to the chase on the bandwidth problem. While I will agree with Hermann that SDR hardware (and the HDL features of HPSDR) seem to be changing as fast or faster than SDR software in recent months, I also think it ought to be the other way around. On the big list of SDR's from Wikipedia http://en.wikipedia.org/wiki/List_of_software-defined_radios I note only 2 devices use PCIe. I think the hardware is changing largely because of all the ways that developers are choosing to deal with the problems of interface constraints; hardware that can filter this amount of data at this datarate is neither easy nor cheap to engineer. There is no need to go to this length if you can just move all the data in the first place. But if the GPU architecture is the way forward, it's just silly to put an intermediate interface that requires a lot of HDL work in the way. For a direct sampling design the most future proof design possible is to make sure the hardware is at minimum capable of sending the raw ADC/DAC/Clock data in and out at full datarate to an attached device. IMO the reason working with the SoCKit hardware and Scotty's boards is probably so nice is because the interface from the FPGA to the software is basically transparent. (This is half speculation as I have a SoCKit that I have used quite a bit but have not yet put funds together for a board set from Scotty) There is no ethernet PHY and framing and protocol to get at the DDC data; the CPU just opens a device and starts reading. If That eliminates a lot of complexity. But you could easily plug his board set into a different dev kit like this http://www.altera.com/products/devkits/altera/kit-cyclone-v-gt.html and with some (admitted) effort you could make yourself a prototype PCIe HPSDR card right now that could do DMA transfers of ADC samples right into GPU memory with the same sort of ease. This is the beauty of a high speed interconnect standard. In this case it is HSMC, useful only within a certain scope, but it makes the point I think. A comment for Marc: From what I have seen Mini-PCIe is generally only ever offered with a x1 interface with the exception of MXM, so it makes more sense to adapt a PCIe card to the mini-PCIe form factor than vice versa; that way the card can be designed as a 4x or such. (It can always be allowed to fall back to 1x) Anyway to sum it all up neatly, a single integrated board like Hermes with a Cyclone V SoC part on board that can be used standalone or plugged in and used as a PCIe card would be pretty attractive HPSDR platform, I gotta say. 73, John KF5SAB _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1409478581.0 From k5so at valornet.com Sun Aug 31 09:29:55 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 31 Aug 2014 10:29:55 -0600 Subject: [hpsdr] Orion/ANAN-200D Orion_v2.7 firmware package release Message-ID: <4571643A-37A2-4780-97D1-3D70793B24C8@valornet.com> All, Orion_v2.7 firmware package is available for download from http://www.k5so.com/HPSDR_downloads.html This version of firmware fixes a failure to key an external amplifiler via the PTT output connector when keyed via the external PTT input pin of the accessory jack when in CW mode and improper behavior of non-breakin CW PTT functionality. I have alerted Phil and Abhi that this issue, corrected earlier in Angelia firmware, exists in any of our firmware designs that have implemented CW generated withing the FPGA, including Hermes and Atlas-based systems. It is my expectation that they will shortly release new versions of their respective firmware packages to include this fix which has now already been applied to the Angelia and Orion firmware. 73, Joe K5SO 1409502595.0 From wb4gcs at wb4gcs.org Sun Aug 31 11:29:21 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Sun, 31 Aug 2014 14:29:21 -0400 Subject: [hpsdr] Multiple Metis on one Ethernet Message-ID: <54036981.2020709@wb4gcs.org> All: Have one HPSDR running. Building the second. FOr now, mercury is set to obtain IP address via DHCP. Any problems putting the second one on the network to update firmware in my very old mercury and penny boards? Thanks & 73, Jim wb4gcs at amsat.org --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1409509761.0 From beford at myfairpoint.net Sun Aug 31 13:01:55 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Sun, 31 Aug 2014 16:01:55 -0400 Subject: [hpsdr] Munin amp kits for sale Message-ID: I purchased two complete kits for Munin when they were offered by Don, K3DLW, but have not built either yet. I would be willing to sell both for what I paid, plus postage. This also includes the PC boards , all components, heat sinks and copper heat spreaders. That would come to $170 each total, including Priority mail to your US address. Check, Money Order, or PayPal would be fine. Please reply off-list. mycall at arrl dot net Thanks, Bruce/N1RX -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 13:30:30 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 15:30:30 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 Message-ID: After about 3 hours worth of work and a few workarounds, I made my first QSO on 20 meters under Linux! I used MonoDevelop as the IDE for the C# KISS solution. I had to make a couple of changes for the P/Invokes of the fftw3f library and some of the Networking calls, which are still not implemented within the Mono CLR. The performance is quite good, I'll compare it to my Windows box to see the differences. Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. I'll document my changes and the dependencies that I installed to make it work soon. Thanks everyone for the welcome and thanks to the authors of KISS Konsole for making the porting easy :) 73, Jae - K5JAE -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 13:36:38 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 15:36:38 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: The link should not have the following '.' at the end. Here it is again: http://i.imgur.com/AsJ4pSE.png On Sun, Aug 31, 2014 at 3:30 PM, Jae Stutzman wrote: > After about 3 hours worth of work and a few workarounds, I made my first > QSO on 20 meters under Linux! > > I used MonoDevelop as the IDE for the C# KISS solution. I had to make a > couple of changes for the P/Invokes of the fftw3f library and some of the > Networking calls, which are still not implemented within the Mono CLR. The > performance is quite good, I'll compare it to my Windows box to see the > differences. > > Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. > I'll document my changes and the dependencies that I installed to make it > work soon. > > Thanks everyone for the welcome and thanks to the authors of KISS Konsole > for making the porting easy :) > > > 73, > > Jae - K5JAE > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.frohne at wallawalla.edu Sun Aug 31 15:12:51 2014 From: rob.frohne at wallawalla.edu (Rob Frohne) Date: Sun, 31 Aug 2014 14:12:51 -0800 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: That's neat Jae! 73, Rob KL7NA On August 31, 2014 12:36:38 PM AKDT, Jae Stutzman wrote: >***** High Performance Software Defined Radio Discussion List ***** > > > >------------------------------------------------------------------------ > >The link should not have the following '.' at the end. Here it is >again: >http://i.imgur.com/AsJ4pSE.png > > > >On Sun, Aug 31, 2014 at 3:30 PM, Jae Stutzman >wrote: > >> After about 3 hours worth of work and a few workarounds, I made my >first >> QSO on 20 meters under Linux! >> >> I used MonoDevelop as the IDE for the C# KISS solution. I had to make >a >> couple of changes for the P/Invokes of the fftw3f library and some of >the >> Networking calls, which are still not implemented within the Mono >CLR. The >> performance is quite good, I'll compare it to my Windows box to see >the >> differences. >> >> Here is a link to a screenshot of how it looks: >http://imgur.com/AsJ4pSE. >> I'll document my changes and the dependencies that I installed to >make it >> work soon. >> >> Thanks everyone for the welcome and thanks to the authors of KISS >Konsole >> for making the porting easy :) >> >> >> 73, >> >> Jae - K5JAE >> >> >> >> > > >------------------------------------------------------------------------ > >_______________________________________________ >HPSDR Discussion List >To post msg: hpsdr at openhpsdr.org >Subscription help: >http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >HPSDR web page: http://openhpsdr.org >Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wb4gcs at wb4gcs.org Sun Aug 31 14:57:25 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Sun, 31 Aug 2014 17:57:25 -0400 Subject: [hpsdr] Trouble updating Mercury firmware Message-ID: <54039A45.8020804@wb4gcs.org> All: I am finally assembling the system I purchased in pieces long ago from TAPR. I have successfully updated Metis firmware to the latest. I have installed J1 in Metis to put it in bootloader mode. I have installed J7 (last JTAG) jumper on Mercury. Running HPSDRProgrammer V2 version 2.0.4.0 All the LEDs on Mercury that the manual says should be lit are. When I click DISCOVER, Mercury is not found, and I get an error message telling me to "Make sure the correct interface is attached. There is only one interface -- the ethernet interface on the computer. Any suggestions?? Thanks & 73, Jim wb4gcs at amsat.org --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1409522245.0 From k5jae at stutzman.net Sun Aug 31 15:54:22 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 17:54:22 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: On a whim, I thought I might try the Jetson TK1 board with mono/kiss konsole. After working out the dependencies, it appears to run OK (I haven't transmitted yet). Anything beyond 96000 sample rate will give audio distortion on the receive. If I choose 192000 and then select NR, it really goes off the rails. Keep in mind that this is completely running within the ARM hard float CPU, which is using the original libfftw3 FFT library. Utilizing a CUDA optimized FFT library would probably give a lot more headroom. Both the spectrum and waterfall displays are ok with some slight hiccup that correspond to audio blips. 73, Jae - K5JAE On Sun, Aug 31, 2014 at 5:12 PM, Rob Frohne wrote: > That's neat Jae! > > 73, > Rob > KL7NA > > On August 31, 2014 12:36:38 PM AKDT, Jae Stutzman > wrote: >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> The link should not have the following '.' at the end. Here it is again: >> http://i.imgur.com/AsJ4pSE.png >> >> >> >> On Sun, Aug 31, 2014 at 3:30 PM, Jae Stutzman wrote: >> >>> After about 3 hours worth of work and a few workarounds, I made my first >>> QSO on 20 meters under Linux! >>> >>> I used MonoDevelop as the IDE for the C# KISS solution. I had to make a >>> couple of changes for the P/Invokes of the fftw3f library and some of the >>> Networking calls, which are still not implemented within the Mono CLR. The >>> performance is quite good, I'll compare it to my Windows box to see the >>> differences. >>> >>> Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. >>> I'll document my changes and the dependencies that I installed to make it >>> work soon. >>> >>> Thanks everyone for the welcome and thanks to the authors of KISS >>> Konsole for making the porting easy :) >>> >>> >>> 73, >>> >>> Jae - K5JAE >>> >>> >>> >>> >> ------------------------------ >> >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Sun Aug 31 16:09:32 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 31 Aug 2014 17:09:32 -0600 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: <6B339E1F-4D1A-4AF4-9404-386B050807B3@valornet.com> Congratulations, Jae! That?s excellent news! I have just this past Thursday assembled a new computer system to allow me to begin exploring Linux. I have installed Ubuntu, Synaptic, Mono-complete, MonoDevelop and am anxious to get rolling on porting some of my Windows C# radio astronomy apps that I have written over to Linux. I am ecstatic to hear that you have KISS ported over now (in such a brief time too!!) and I am very interested to see how you did it. Also, I too have a strong interest in porting PowerSDR over to Linux and I have heard of your vast experience in such porting activities. I am quite excited to learn of any progress that you make there so please do give us updates as to your progress. I, naively of course, intended to give it a try myself as soon as I gain more familiarity with Linux, and Mono in particular. I currently use Visual Studio 2013 to make mods to the PowerSDR code from time to time but I?m not a professional programmer and barely squeak along with VS to be truthful; but I?m continuing to learn all the time and am getting more proficient, I hope. I am a complete newbie with respect to Linux so please don?t be overly brief in your ?how to? descriptions or they?ll go completely over my head for sure. Thanks, and congrats again! 73, Joe K5SO 1409526572.0 From g3vbv at blueyonder.co.uk Sun Aug 31 16:20:51 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 01 Sep 2014 00:20:51 +0100 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: <5403ADD3.2020209@blueyonder.co.uk> Neat. Back in May 2013 I posted the following but didn't get a reply. This was using the .exe under Crossover Office. ------------------------------------------------------------------------------------ For curiosity value mainly. Just seeing if anyone has an idea what's happening. Appending screenshots exceeds the allowed email limit. I select HERMES and when I click ON I get a string of these messages, it sees Hermes on 192.168.10.77 then the 127.12.34.56 Metis stuff, Metis is not selected, only Hermes with 2.4 firmware. Found a Metis/Hermes/Griffin. Checking whether it qualifies Metis IP from IP Header = 192.168.10.77 Metis MAC address from payload = 00-04-A3-6A-21-BE Not on subnet of host adapter! Adapter IP 127.12.34.56, Adapter mask 255.255.255.255 No data from Port = Ready to receive.... raw Discovery data = EF-FE-02-00-04-A3-6A-21-BE-18-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 -01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 ----------------------------------------------------------------------------------------------------------------------- 73 ... Sid. On 31/08/14 21:30, Jae Stutzman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > After about 3 hours worth of work and a few workarounds, I made my > first QSO on 20 meters under Linux! > > I used MonoDevelop as the IDE for the C# KISS solution. I had to make > a couple of changes for the P/Invokes of the fftw3f library and some > of the Networking calls, which are still not implemented within the > Mono CLR. The performance is quite good, I'll compare it to my Windows > box to see the differences. > > Here is a link to a screenshot of how it looks: > http://imgur.com/AsJ4pSE. I'll document my changes and the > dependencies that I installed to make it work soon. > > Thanks everyone for the welcome and thanks to the authors of KISS > Konsole for making the porting easy :) > > > 73, > > Jae - K5JAE > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 16:25:48 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 18:25:48 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: <6B339E1F-4D1A-4AF4-9404-386B050807B3@valornet.com> References: <6B339E1F-4D1A-4AF4-9404-386B050807B3@valornet.com> Message-ID: Joe, This is obviously a proof of concept at this point. Some of the issues I experienced years ago with Mono and WinForms are still there. Namely, rendering issues. On Windows, WinForms is a thin wrapper on top of native Windows libraries. On Linux, the Mono team wrote the entire library in managed code before diving into the native X Windows UI layer. What I find is that initial widget rendering is a bit slow and then size and location of widgets don't always render correctly. However, the UI seems usable. I'll definitely relay my findings to this group. More to follow :) 73, Jae - K5JAE On Aug 31, 2014 6:09 PM, "Joe Martin K5SO" wrote: > Congratulations, Jae! That?s excellent news! > > I have just this past Thursday assembled a new computer system to allow me > to begin exploring Linux. I have installed Ubuntu, Synaptic, > Mono-complete, MonoDevelop and am anxious to get rolling on porting some of > my Windows C# radio astronomy apps that I have written over to Linux. I am > ecstatic to hear that you have KISS ported over now (in such a brief time > too!!) and I am very interested to see how you did it. > > Also, I too have a strong interest in porting PowerSDR over to Linux and I > have heard of your vast experience in such porting activities. I am quite > excited to learn of any progress that you make there so please do give us > updates as to your progress. I, naively of course, intended to give it a > try myself as soon as I gain more familiarity with Linux, and Mono in > particular. I currently use Visual Studio 2013 to make mods to the > PowerSDR code from time to time but I?m not a professional programmer and > barely squeak along with VS to be truthful; but I?m continuing to learn all > the time and am getting more proficient, I hope. > > I am a complete newbie with respect to Linux so please don?t be overly > brief in your ?how to? descriptions or they?ll go completely over my head > for sure. > > Thanks, and congrats again! > > 73, Joe K5SO > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 17:03:01 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 19:03:01 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: <5403ADD3.2020209@blueyonder.co.uk> Message-ID: Sid, I've only used CrossOver for a couple of things. There is a big difference to running and exe within CX and Mono. First, CX is a reimplementation of win32/64 native libraries under Linux and libc. It intends to allow win apps to run as though they are on windows. This means you install .NET on top of CX to run C# apps. It has been moderately successful and a huge undertaking! Mono, on the other hand is a reimplementation of the CLR/CLI. It doesn't bring in any win32/64 APIs and is a clean room implementation. It would be analogous to the JVM running on Linux vs running on Windows, except that MS didn't provide a Linux version so the OSS community wrote it themselves. I view CX as a compromise to bring windows applications to Linux. I view Mono as a first class development and runtime environment where Linux apps can be made and executed. That said. I like cross platform development. With careful consideration an app can look and run as if native on many different platforms. As far as your log, I'm not sure what was going on! Except it looks like it had something to do with the network interface. 73, Jae > On Aug 31, 2014 6:20 PM, "Sid Boyce" wrote: >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> >> Neat. >> Back in May 2013 I posted the following but didn't get a reply. This was using the .exe under Crossover Office. >> ------------------------------------------------------------------------------------ >> For curiosity value mainly. >> Just seeing if anyone has an idea what's happening. >> Appending screenshots exceeds the allowed email limit. >> >> I select HERMES and when I click ON I get a string of these messages, it sees Hermes on 192.168.10.77 then the 127.12.34.56 Metis stuff, Metis is not selected, only Hermes with 2.4 firmware. >> >> Found a Metis/Hermes/Griffin. Checking whether it qualifies >> Metis IP from IP Header = 192.168.10.77 >> Metis MAC address from payload = 00-04-A3-6A-21-BE >> Not on subnet of host adapter! Adapter IP 127.12.34.56, Adapter mask 255.255.255.255 >> No data from Port = >> Ready to receive.... >> raw Discovery data = EF-FE-02-00-04-A3-6A-21-BE-18-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 >> -01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 >> ----------------------------------------------------------------------------------------------------------------------- >> 73 ... Sid. >> >> On 31/08/14 21:30, Jae Stutzman wrote: >>> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> >>> >>> After about 3 hours worth of work and a few workarounds, I made my first QSO on 20 meters under Linux! >>> >>> I used MonoDevelop as the IDE for the C# KISS solution. I had to make a couple of changes for the P/Invokes of the fftw3f library and some of the Networking calls, which are still not implemented within the Mono CLR. The performance is quite good, I'll compare it to my Windows box to see the differences. >>> >>> Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. I'll document my changes and the dependencies that I installed to make it work soon. >>> >>> Thanks everyone for the welcome and thanks to the authors of KISS Konsole for making the porting easy :) >>> >>> >>> 73, >>> >>> Jae - K5JAE >>> >>> >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> >> >> -- >> 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 >> >> >> _______________________________________________ >> >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wp4o at tampabay.rr.com Sun Aug 31 17:42:30 2014 From: wp4o at tampabay.rr.com (ed) Date: Sun, 31 Aug 2014 20:42:30 -0400 Subject: [hpsdr] anan 100 forsale Message-ID: <000001cfc57d$9cad2310$d6076930$@tampabay.rr.com> Selling my extra ANAN 100 has new Smps regulator and VCXO Runs very cool. E mail me if interested. Thanks and 73, Ed KK4x, Tampa Florida -------------- next part -------------- An HTML attachment was scrubbed... URL: From kv0s.dave at gmail.com Sun Aug 31 18:15:24 2014 From: kv0s.dave at gmail.com (Dave Larsen) Date: Sun, 31 Aug 2014 20:15:24 -0500 Subject: [hpsdr] Trouble updating Mercury firmware In-Reply-To: <54039A45.8020804@wb4gcs.org> References: <54039A45.8020804@wb4gcs.org> Message-ID: Jim Almost right There are two programs, HPSDRProgrammer V2 only talks to boards with ethernet sockets and does not need the j1 jumper but it will not program through a JTAG port. the second program HPSDRBootloader is for use in the Bootloader mode as you specified. If you follow your steps, EXCEPT use HPSDRBootloader it should work.. HPSDRBootloader uses the pcap library, the J1 jumper and a raw Ethernet packets and cane be used as a JTAG programmer for boards with no Ethernet connector. HPSDRProgrammer V2 is use UDP, no jumper and old firmware newer that 2.3, This is convenients for update firmware without opening the box. But if the old firmware is broke it will not work. PS. HPSDRProgrammer V1.6 does both tasks but people got confused different problem and what part of the program when with each task. Dave KV0S HPSDRProgrammer V2 and HPSDRBootloader Programmer and Maintainer On Sun, Aug 31, 2014 at 4:57 PM, Jim Sanford wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All: > I am finally assembling the system I purchased in pieces long ago from > TAPR. > > I have successfully updated Metis firmware to the latest. > > I have installed J1 in Metis to put it in bootloader mode. > > I have installed J7 (last JTAG) jumper on Mercury. > > Running HPSDRProgrammer V2 version 2.0.4.0 > > All the LEDs on Mercury that the manual says should be lit are. > > When I click DISCOVER, Mercury is not found, and I get an error message > telling me to "Make sure the correct interface is attached. There is only > one interface -- the ethernet interface on the computer. > > Any suggestions?? > > Thanks & 73, > Jim > wb4gcs at amsat.org > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/ > listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- KV0S - Dave Larsen Columbia, MO, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: From wb4gcs at wb4gcs.org Sun Aug 31 18:21:11 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Sun, 31 Aug 2014 21:21:11 -0400 Subject: [hpsdr] Trouble updating Mercury firmware In-Reply-To: References: <54039A45.8020804@wb4gcs.org> Message-ID: <5403CA07.2010802@wb4gcs.org> That did it, thanks!!!!! 73, Jim wb4gcs at amsat.org On 8/31/2014 9:15 PM, Dave Larsen wrote: > Jim > > Almost right > > There are two programs, HPSDRProgrammer V2 only talks to boards with > ethernet sockets and does not need the j1 jumper but it will not > program through a JTAG port. > > the second program HPSDRBootloader is for use in the Bootloader mode > as you specified. If you follow your steps, EXCEPT use > HPSDRBootloader it should work.. > > HPSDRBootloader uses the pcap library, the J1 jumper and a raw > Ethernet packets and cane be used as a JTAG programmer for boards with > no Ethernet connector. > > HPSDRProgrammer V2 is use UDP, no jumper and old firmware newer that > 2.3, This is convenients for update firmware without opening the box. > But if the old firmware is broke it will not work. > > > PS. HPSDRProgrammer V1.6 does both tasks but people got confused > different problem and what part of the program when with each task. > > Dave KV0S HPSDRProgrammer V2 and HPSDRBootloader Programmer and > Maintainer > > > On Sun, Aug 31, 2014 at 4:57 PM, Jim Sanford > wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > All: > I am finally assembling the system I purchased in pieces long ago > from TAPR. > > I have successfully updated Metis firmware to the latest. > > I have installed J1 in Metis to put it in bootloader mode. > > I have installed J7 (last JTAG) jumper on Mercury. > > Running HPSDRProgrammer V2 version 2.0.4.0 > > All the LEDs on Mercury that the manual says should be lit are. > > When I click DISCOVER, Mercury is not found, and I get an error > message telling me to "Make sure the correct interface is > attached. There is only one interface -- the ethernet interface on > the computer. > > Any suggestions?? > > Thanks & 73, > Jim > wb4gcs at amsat.org > > > --- > This email is free from viruses and malware because avast! > Antivirus protection is active. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > > -- > KV0S - Dave Larsen > Columbia, MO, USA --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From beford at myfairpoint.net Sun Aug 31 18:41:29 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Sun, 31 Aug 2014 21:41:29 -0400 Subject: [hpsdr] SOLD Munin amp kits for sale Message-ID: Both Munin amps kits have been spoken for, pending funds. Thanks for all the replies. Bruce N1RX -------------- next part -------------- An HTML attachment was scrubbed... URL: From getpri at t-online.de Sun Aug 31 23:24:58 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 01 Sep 2014 08:24:58 +0200 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: <5404113A.1000700@t-online.de> Hello Jae, wow, good to hear that you were successful so fast. I am interested in your experience to port everything into Ubuntu. I updated my system to Ubuntu 14.04 last week, but I am not very happy with my system as it seems to have some problems. I guess I have to start with a new OS from a CD instead of upgrading. As I am running a dual boot (win7/ubuntu) OS, it is always a problem loading one system from scratch, only. So, I am just in front of starting with HPSDR on linux and eager to get informations about all the pitfalls. 73, Georg DL2KP Am 31.08.2014 22:30, schrieb Jae Stutzman: > ***** High Performance Software Defined Radio Discussion List ***** > > > > After about 3 hours worth of work and a few workarounds, I made my > first QSO on 20 meters under Linux! > > I used MonoDevelop as the IDE for the C# KISS solution. I had to make > a couple of changes for the P/Invokes of the fftw3f library and some > of the Networking calls, which are still not implemented within the > Mono CLR. The performance is quite good, I'll compare it to my Windows > box to see the differences. > > Here is a link to a screenshot of how it looks: > http://imgur.com/AsJ4pSE. I'll document my changes and the > dependencies that I installed to make it work soon. > > Thanks everyone for the welcome and thanks to the authors of KISS > Konsole for making the porting easy :) > > > 73, > > Jae - K5JAE > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Internet: in progress ********************************************************************** IMPORTANTE/IMPORTANT CONFIDENCIAL/CONFIDENTIALITY Este mensaje ha sido elaborado ?nicamente para uso de la persona o entidad a la que es remitido, ya que puede contener informaci?n personal, confidencial y de acuerdo a ley no puede ser difundido. Si el lector de este mensaje no es el destinatario se?alado, o la persona responsable para entregar el mensaje a quien est? dirigido, advertimos que cualquier divulgaci?n, retransmisi?n o copia de esta comunicaci?n esta estrictamente prohibida. Si usted ha recibido esta comunicaci?n por error, por favor s?rvase informarlo de inmediato al remitente por correo electr?nico o tel?fono y borrar inmediatamente el mensaje original. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail kann vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ********************************************************************** --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From la2ni at online.no Fri Aug 1 00:26:03 2014 From: la2ni at online.no (Kjell Karlsen) Date: Fri, 01 Aug 2014 09:26:03 +0200 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: Congratulations Warren! 73, Kjell, LA2NI P? Fri, 01 Aug 2014 07:05:14 +0200, skrev Bill Tracey : > ***** High Performance Software Defined Radio Discussion List ***** > > From > http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, > NR0V, of Santa Cruz, California. Pratt was cited for his research > leading to the development of PureSignal, "an adaptive baseband > pre-distortion algorithm used to improve the linearity of amplifiers and > reduce intermodulation distortion products emitted by software-defined > transmitters." > > Congratulations Warren, and thanks for your excellent contributions! > > Bill (kd5tfd) > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > -- Sendt med Operas e-postklient: http://www.opera.com/mail/ 1406877963.0 From meijer.ha at home.nl Fri Aug 1 00:56:10 2014 From: meijer.ha at home.nl (H.A. Meijer) Date: Fri, 1 Aug 2014 09:56:10 +0200 (CEST) Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: <1644767958.114768.1406879772837.open-xchange@oxbe3.tb.mail.iss.local> An HTML attachment was scrubbed... URL: From w4yn at earthlink.net Fri Aug 1 04:38:50 2014 From: w4yn at earthlink.net (Tim ORourke) Date: Fri, 1 Aug 2014 07:38:50 -0400 (GMT-04:00) Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner Message-ID: <3589696.1406893130994.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> This is way cool, tnx for all the FB effort for a fantastic solution! Tim Tim O\Rourke W4YN at ARRL.Net Low Power Amateur Radio Rocks Member of Flying Pigs,ARCI,GQRP,RSGB,ARRL Life Member R/C Pilot (sort of) NRA Life Member NRA Certified Rifle, Pistol, Black Powder Instructor, Range Officer -----Original Message----- >From: Bill Tracey >Sent: Aug 1, 2014 1:05 AM >To: HPSDR list >Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner > >***** High Performance Software Defined Radio Discussion List ***** > > From >http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > > * The 2014 ARRL Technical Innovation Award went to Warren C. >Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his >research leading to the development of PureSignal, "an adaptive >baseband pre-distortion algorithm used to improve the linearity of >amplifiers and reduce intermodulation distortion products emitted by >software-defined transmitters." > >Congratulations Warren, and thanks for your excellent contributions! > >Bill (kd5tfd) > > >_______________________________________________ >HPSDR Discussion List >To post msg: hpsdr at openhpsdr.org >Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >HPSDR web page: http://openhpsdr.org >Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1406893130.0 From g3vbv at blueyonder.co.uk Fri Aug 1 05:02:31 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Fri, 01 Aug 2014 13:02:31 +0100 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: <53DB81D7.8000506@blueyonder.co.uk> Brilliant News! Absolutely! 73 ... Sid. On 01/08/14 06:05, Bill Tracey wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > From > http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > > * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, > NR0V, of Santa Cruz, California. Pratt was cited for his research > leading to the development of PureSignal, "an adaptive baseband > pre-distortion algorithm used to improve the linearity of amplifiers > and reduce intermodulation distortion products emitted by > software-defined transmitters." > > Congratulations Warren, and thanks for your excellent contributions! > > Bill (kd5tfd) > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > . > -- 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 1406894551.0 From abhiarunoday at gmail.com Fri Aug 1 07:06:25 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Fri, 1 Aug 2014 19:36:25 +0530 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner Message-ID: Congratulations Warren, well deserved, Please let me also add that it is a pleasure and an honor to work with Warren, Kudos!!!! Abhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From nealk3nc at gmail.com Fri Aug 1 07:58:12 2014 From: nealk3nc at gmail.com (Neal Campbell) Date: Fri, 1 Aug 2014 10:58:12 -0400 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: References: Message-ID: He is unbelievably talented as well as an incredibly smart dude! Add generous to that list also. Congrats Warren, I could not imagine a more worthy person. 73 Neal Campbell Abroham Neal LLC On Fri, Aug 1, 2014 at 10:06 AM, Abhi A wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > Congratulations Warren, well deserved, > > Please let me also add that it is a pleasure and an honor to work with > Warren, > > Kudos!!!! > > Abhi > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scotty at tonks.com Fri Aug 1 11:23:07 2014 From: scotty at tonks.com (Scott Cowling) Date: Fri, 01 Aug 2014 11:23:07 -0700 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com > References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: <7.0.1.0.2.20140801112159.04ddfcf0@tonks.com> Congratulations, Warren! Very well deserved! 73, Scotty WA2DFI At 00:05 2014-08-01 -0500, Bill Tracey wrote: >***** High Performance Software Defined Radio Discussion List ***** > > From > http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients > > * The 2014 ARRL Technical Innovation Award went to Warren C. > Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his > research leading to the development of PureSignal, "an adaptive > baseband pre-distortion algorithm used to improve the linearity of > amplifiers and reduce intermodulation distortion products emitted > by software-defined transmitters." > >Congratulations Warren, and thanks for your excellent contributions! > >Bill (kd5tfd) 1406917387.0 From ve7mdl at gmail.com Fri Aug 1 12:03:33 2014 From: ve7mdl at gmail.com (Erik Skovgaard) Date: Fri, 1 Aug 2014 12:03:33 -0700 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk> <53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: Congratulations Warren and thanks for all your hard work! 73 de ve7mdl, ....Erik. Currently marine mobile as ve0mdl On Jul 31, 2014 10:05 PM, "Bill Tracey" wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > From http://www.arrl.org/news/arrl-board-lauds-unforgettable- > milestone-formalizes-lotw-policy-honors-award-recipients > * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, > NR0V, of Santa Cruz, California. Pratt was cited for his research leading > to the development of PureSignal, "an adaptive baseband pre-distortion > algorithm used to improve the linearity of amplifiers and reduce > intermodulation distortion products emitted by software-defined > transmitters." > > Congratulations Warren, and thanks for your excellent contributions! > > Bill (kd5tfd) > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/ > listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beford at myfairpoint.net Fri Aug 1 12:43:56 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Fri, 1 Aug 2014 15:43:56 -0400 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Message-ID: Well deserved recognition for a remarkable advancement of the radio art. Congratulations. Bruce/N1RX 1406922236.0 From tfox at knology.net Fri Aug 1 16:40:59 2014 From: tfox at knology.net (Terry Fox) Date: Fri, 1 Aug 2014 19:40:59 -0400 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner In-Reply-To: <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> References: <53DA4FDA.60600@blueyonder.co.uk><53DABB09.6060104@blueyonder.co.uk> <201408010505.s71556Dv008606@mail24c25-2209.carrierzone.com> Message-ID: I just got in from a day of antenna work, and saw this. Congratulations Warren!!! Your commitment to moving PureSignal forward, along with other SDR work, is impressive indeed!! Keep it up! 73, Terry, WB4JFI -----Original Message----- From: Bill Tracey Sent: Friday, August 01, 2014 1:05 AM To: HPSDR list Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner ***** High Performance Software Defined Radio Discussion List ***** From http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients * The 2014 ARRL Technical Innovation Award went to Warren C. Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his research leading to the development of PureSignal, "an adaptive baseband pre-distortion algorithm used to improve the linearity of amplifiers and reduce intermodulation distortion products emitted by software-defined transmitters." Congratulations Warren, and thanks for your excellent contributions! Bill (kd5tfd) _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1406936459.0 From aa8k73 at gmail.com Fri Aug 1 21:24:26 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Sat, 02 Aug 2014 00:24:26 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/02 Message-ID: <53DC67FA.8060802@gmail.com> The 2/Aug TeamSpeak mp3 (67 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3509 > or < http://www.hamsdr.com/dnld.aspx > Session text follows <20:56:42> *** You are now talking in channel: "OpenHPSDR" <21:00:14> "Mike - AA8K": Congratulations Warren! <21:01:04> "Terry WB4JFI": Yes, Congratulations Warren!! Good work there! <21:01:51> "Warren - NR0V": Thanks very much. I enjoy the work and feel honored to be recognized. <21:24:05> "Mike - AA8K": Recordings: It's my way of contributing to the projects. :) <21:51:39> "Ken N9VV": Basic Configuration ? Tegra K1 SOC ? 2 Gbyte x16 memory with 64 bit width (can accommodate from 1-4 GByte total) ? 16GB 4.51 eMMC memory (footprint expandable from 16-256GByte memory) ? One empty half mini-PCIE slot with one USB and single lane PEX ? One SD/MMC connector ? One USB 2.0 port, micro AB ? One USB 3.0 port, type A ? HDMI port, type A ? TMP451 temperature monitor ? RS232 Serial port routed to UART4 ? ALC5639 Realtek Audio codec with separate MIC in and Line out jacks ? RTL8111GS Realtek GigE LAN/PHY with PEX interface ? One SATA data port ? SPI 4MByte Boot Flash device ? AMS AS3722 Power Management IC for power and sequencing ? Board ID EEPROM Signal Groups Routing to Expansion Headers ? DP / LVDS ? Touch SPI ? Camera_0 (one CSI differential data pair) & Camera_1 (four CSI differential data pairs) <21:51:46> "Ken N9VV": ? GPIO PU(6:0) general purpose IO ? UART ? HSIC ? GEN(2:1)_I2C, PWR_I2C, CAM_I2C ? Miscellaneous Power Connectors and Expansion Headers ? USB 2.0 OTG ? USB 3.0, flag configuration ? 2mm pitch Expansion headers (5x25 configuration) ? RJ45 ethernet with integrated gigabit magnetics ? HDMI type A port ? DSUB9 male serial port ? MIC-in, Headphone-out 3.5mm jacks ? JTAG 2x10 100 mil pitch THM (Through Hole Mount) ? DC power jack <21:52:37> "Rob - VE3EW": rob creswon rcrewson{AT}cinci.rr.com <21:52:53> "Rob - VE3EW": u can see i done type well <21:56:50> "Ken N9VV": Already announced Tablet last week <21:59:52> "Ken N9VV": July 23rd: < http://blogs.nvidia.com/blog/2014/07/23/why-shield-family/ > <22:01:11> "Ken N9VV": < http://www.androidheadlines.com/2014/07/nvidia-shield-tablet-now-available-299.html > <22:02:24> "Ken N9VV": Nvidia Shield Tablet for sale $299 from Amazon <22:06:51> "Ken N9VV": Lake Superior is 1,335 feet deep and 350 miles long. <22:07:05> "Ken N9VV": < http://en.wikipedia.org/wiki/Great_Lakes > <22:11:30> "Warren - NR0V": 73 ... time to go check with the XYL on the dinner plans 1406953466.0 From nu8i at cox.net Sat Aug 2 12:47:29 2014 From: nu8i at cox.net (Alfred Green) Date: Sat, 02 Aug 2014 12:47:29 -0700 Subject: [hpsdr] FM squelch Message-ID: <53DD4051.5010902@cox.net> Greetings, I'm currently using mRX PS v3.2.17 with a Hermes and homebrew transverters. I rarely operate FM, but a local station was active for the UHF contest with an FM rig on 1296, so I worked him for the point. However, the signal was pretty weak, although quite visible on the waterfall. I would have liked to have opened the squelch to assist with the copy, but setting SQL to zero didn't do the trick. I had to wait for the signal to get a good ways over the noise before the rx would open. I'm pretty sure this worked differently in an earlier release, but as I rarely do this I could be mistaken. Am I missing a setting, or is this performance to be expected? 73 Alf NU8I Phoenix AZ DM33xo 1407008849.0 From n9vv at wowway.com Sat Aug 2 13:50:40 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Sat, 02 Aug 2014 15:50:40 -0500 Subject: [hpsdr] FM squelch In-Reply-To: <53DD4051.5010902@cox.net> References: <53DD4051.5010902@cox.net> Message-ID: <53DD4F20.3020007@wowway.com> I am not sure that I can offer you a good explanation about this Alf, but you might want to use a calibrated signal source like the Elecraft XG-1 which emits a 50uv = S9 = -73db signal at 7040, and has another setting of -113db = S1 = ?uv with a switch. You can then know that your receiver is properly calibrated with any sort of input. I believe some of the more modern Elecraft calibrators allow you to select any frequency you wish. Perhaps you could substitute the calibrated signal for the IF signal coming from the transverter, and then adjust the SQUELCH on/off and level slider as needed to verify it's tripping levels in your setup. GL de Ken N9VV On 8/2/2014 2:47 PM, Alfred Green wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Greetings, > > I'm currently using mRX PS v3.2.17 with a Hermes and homebrew transverters. > > I rarely operate FM, but a local station was active for the UHF contest > with an FM rig on 1296, so I worked him for the point. > However, the signal was pretty weak, although quite visible on the > waterfall. I would have liked to have opened the squelch to assist with > the copy, but setting SQL to zero didn't do the trick. I had to wait for > the signal to get a good ways over the noise before the rx would open. > > I'm pretty sure this worked differently in an earlier release, but as I > rarely do this I could be mistaken. > > Am I missing a setting, or is this performance to be expected? > > 73 Alf NU8I > Phoenix AZ DM33xo > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1407012640.0 From nu8i at cox.net Sat Aug 2 16:34:44 2014 From: nu8i at cox.net (Alfred Green) Date: Sat, 02 Aug 2014 16:34:44 -0700 Subject: [hpsdr] FM squelch In-Reply-To: References: <53DD4051.5010902@cox.net> Message-ID: <53DD7594.8060509@cox.net> On 8/2/2014 1:50 PM, Ken N9VV (Win-7/64) wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I am not sure that I can offer you a good explanation about this Alf, > but you might want to use a calibrated signal source like the Elecraft > XG-1 which emits a 50uv = S9 = -73db signal at 7040, and has another > setting of -113db = S1 = ?uv with a switch. > > You can then know that your receiver is properly calibrated with any > sort of input. I believe some of the more modern Elecraft calibrators > allow you to select any frequency you wish. > > Perhaps you could substitute the calibrated signal for the IF signal > coming from the transverter, and then adjust the SQUELCH on/off and > level slider as needed to verify it's tripping levels in your setup. > Tnx for the comments, Ken. The IF is well calibrated; in fact I have good sources through 10Gigs so that is not the issue. When you mentioned "adjust the SQUELCH on/off and level slider" I had an 'ah-ha' moment; clicking on the 'SQL: xx' box turns on/off the squelch. I had forgotten that was a control, but it does exactly what I needed. Maybe I should just RTFM. GL & 73, Alf NU8I 1407022484.0 From warren at wpratt.com Sat Aug 2 19:22:37 2014 From: warren at wpratt.com (Warren C. Pratt) Date: Sat, 02 Aug 2014 19:22:37 -0700 Subject: [hpsdr] FM squelch In-Reply-To: <53DD7594.8060509@cox.net> References: <53DD4051.5010902@cox.net> <53DD7594.8060509@cox.net> Message-ID: <53DD9CED.4050900@wpratt.com> Hi Alf, I got out the FM signal generator and did a quick check. All here seems to be working as expected. Setting differences could be the issue. The thing to check first is the sample rate. Because of the bandwidths involved in FM demodulation and modulation, I would not recommend using less than a 192K sample rate for FM. DSP Buffer Size might also be relevant. At 192K, I'd use 4096. In any case, if you are still having difficulty, you've found the workaround for the moment -- the squelch OFF button. Let me know if sample rate / DSP buffer size helps. 73, Warren NR0V On 8/2/2014 4:34 PM, Alfred Green wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > On 8/2/2014 1:50 PM, Ken N9VV (Win-7/64) wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> I am not sure that I can offer you a good explanation about this Alf, >> but you might want to use a calibrated signal source like the >> Elecraft XG-1 which emits a 50uv = S9 = -73db signal at 7040, and has >> another setting of -113db = S1 = ?uv with a switch. >> >> You can then know that your receiver is properly calibrated with any >> sort of input. I believe some of the more modern Elecraft calibrators >> allow you to select any frequency you wish. >> >> Perhaps you could substitute the calibrated signal for the IF signal >> coming from the transverter, and then adjust the SQUELCH on/off and >> level slider as needed to verify it's tripping levels in your setup. >> > > Tnx for the comments, Ken. > The IF is well calibrated; in fact I have good sources through 10Gigs > so that is not the issue. > When you mentioned "adjust the SQUELCH on/off and level slider" I had > an 'ah-ha' moment; clicking on the 'SQL: xx' box turns on/off the > squelch. I had forgotten that was a control, but it does exactly what > I needed. > > Maybe I should just RTFM. > > GL & 73, Alf NU8I > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1407032557.0 From nu8i at cox.net Sun Aug 3 08:02:40 2014 From: nu8i at cox.net (Alfred Green) Date: Sun, 03 Aug 2014 08:02:40 -0700 Subject: [hpsdr] FM squelch In-Reply-To: References: <53DD4051.5010902@cox.net> <53DD7594.8060509@cox.net> Message-ID: <53DE4F10.3090503@cox.net> On 8/2/2014 7:22 PM, Warren C. Pratt wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Alf, > > I got out the FM signal generator and did a quick check. All here > seems to be working as expected. Setting differences could be the > issue. The thing to check first is the sample rate. Because of the > bandwidths involved in FM demodulation and modulation, I would not > recommend using less than a 192K sample rate for FM. DSP Buffer Size > might also be relevant. At 192K, I'd use 4096. > > In any case, if you are still having difficulty, you've found the > workaround for the moment -- the squelch OFF button. > > Let me know if sample rate / DSP buffer size helps. > Hello Warren, I appreciate the comments. I'm running at 48k sample rate with 2048 rx buffer size. If I change to 192k sr the squelch slider seems to operate more like I was expecting, ie. with no or little signal, setting squelch to 0 opens the Rx. That may be how I had it set before, so my old memory may not be failing. However, it really isn't an issue anymore, as I have found the on/off button. I have now had a whopping 2 contacts on FM in the last year or so; usually I am on CW/SSB/JT on UHF and up. It was just that a local had an FM HT with him that would work on 1296, so it was worth a shot for a point. If anyone is planning on using FM more seriously then the note about sample rate would be an important consideration. Tnx for everything. 73 Alf NU8I Phoenix AZ DM33xo 1407078160.0 From i7swx at yahoo.com Sun Aug 3 08:39:01 2014 From: i7swx at yahoo.com (Giancarlo Moda) Date: Sun, 3 Aug 2014 16:39:01 +0100 Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical Innovation Award winner Message-ID: <1407080341.82109.YahooMailNeo@web172003.mail.ir2.yahoo.com> THE VERY BEST CONGRATULATIONS WARREN, this is the minimum we can say for the Aword you received and more for your "brain" contribution to the Ham and professional fields 73 Gian I7SWX Message: 3 Date: Fri, 01 Aug 2014 00:05:14 -0500 From: Bill Tracey To: HPSDR list Subject: [hpsdr] Congrats to Warren Pratt (NR0V) - 2014 ARRL Technical ??? Innovation Award winner Message-ID: ??? <201408010505.s71556Dv008606 at mail24c25-2209.carrierzone.com> Content-Type: text/plain; charset="us-ascii"; format=flowed From? http://www.arrl.org/news/arrl-board-lauds-unforgettable-milestone-formalizes-lotw-policy-honors-award-recipients? ? ? * The 2014 ARRL Technical Innovation Award went to Warren C.? Pratt, NR0V, of Santa Cruz, California. Pratt was cited for his? research leading to the development of PureSignal, "an adaptive? baseband pre-distortion algorithm used to improve the linearity of? amplifiers and reduce intermodulation distortion products emitted by? software-defined transmitters." Congratulations Warren, and thanks for your excellent contributions! Bill (kd5tfd) -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From getpri at t-online.de Mon Aug 4 05:18:57 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 04 Aug 2014 14:18:57 +0200 Subject: [hpsdr] PowerSDR and OZY In-Reply-To: <53DD9CED.4050900@wpratt.com> References: <53DD4051.5010902@cox.net> <53DD7594.8060509@cox.net> <53DD9CED.4050900@wpratt.com> Message-ID: <53DF7A31.4050102@t-online.de> Hello, what is the latest version of PowerSDR working with OZY? What are the appropriate firmware versions for Mercury and Penylane? 73, Georg, DL2KP --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com 1407154737.0 From vk5lb at yahoo.com.au Mon Aug 4 07:14:27 2014 From: vk5lb at yahoo.com.au (Dean) Date: Mon, 4 Aug 2014 23:44:27 +0930 Subject: [hpsdr] PwrSDR with Ozy Message-ID: Like Georg, there are many who are happy with Ozy, Mercury and Penelope running an old XP version of PwrSDR. I also would like to hear what people are running as far as XP versions of PwrSDR are concerned. I use 1.19.3.4 by W5WC and it is fine. Penelope 1.2 and Mercury 2.9 with single Rx. However is there a better choice? Cheers Dean. 1407161667.0 From getpri at t-online.de Mon Aug 4 07:44:14 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 04 Aug 2014 16:44:14 +0200 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: References: Message-ID: <53DF9C3E.8010709@t-online.de> Hi Dean, on my OZY-system, I am running OpenHPSDRmRX-FFT v3.2.1(12/23/13). The question is, if there are newer versions compatibel with OZY. I remember that somebody mentioned on this forum, that this should be the last version for OZY, but I am not shure. 73, Georg, dl2kp Am 04.08.2014 16:14, schrieb Dean: > ***** High Performance Software Defined Radio Discussion List ***** > > Like Georg, there are many who are happy with Ozy, Mercury and Penelope running an old XP version of PwrSDR. I also would like to hear what people are running as far as XP versions of PwrSDR are concerned. I use 1.19.3.4 by W5WC and it is fine. Penelope 1.2 and Mercury 2.9 with single Rx. However is there a better choice? > > Cheers Dean. > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- Internet: in progress ********************************************************************** IMPORTANTE/IMPORTANT CONFIDENCIAL/CONFIDENTIALITY Este mensaje ha sido elaborado ?nicamente para uso de la persona o entidad a la que es remitido, ya que puede contener informaci?n personal, confidencial y de acuerdo a ley no puede ser difundido. Si el lector de este mensaje no es el destinatario se?alado, o la persona responsable para entregar el mensaje a quien est? dirigido, advertimos que cualquier divulgaci?n, retransmisi?n o copia de esta comunicaci?n esta estrictamente prohibida. Si usted ha recibido esta comunicaci?n por error, por favor s?rvase informarlo de inmediato al remitente por correo electr?nico o tel?fono y borrar inmediatamente el mensaje original. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail kann vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ********************************************************************** --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com 1407163454.0 From ct1izu at sapo.pt Mon Aug 4 08:54:18 2014 From: ct1izu at sapo.pt (ct1izu) Date: Mon, 4 Aug 2014 16:54:18 +0100 Subject: [hpsdr] PwrSDR with Ozy References: Message-ID: <3C85201767F1422FBF481CBE40D6E427@dd52f851956584> Hi Dean My system at CT1IZU is OZY 2.1 Merc 3.1 Penny 1.6 used on a mini ITX D525 (1.8ghz) from Asus running an Nlited XP with SP2. works well but there are some issues on shutdown with it notnot saving data correctly. Shel CT1IZU 1407167658.0 From ct1izu at sapo.pt Mon Aug 4 08:58:42 2014 From: ct1izu at sapo.pt (ct1izu) Date: Mon, 4 Aug 2014 16:58:42 +0100 Subject: [hpsdr] PwrSDR with Ozy References: Message-ID: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> Dean Too much Vino Tinto Missed the important info pwr SDR Ver 3.2.9 2.23.14 Shel CT1IZU 1407167922.0 From k5so at valornet.com Mon Aug 4 09:38:47 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 4 Aug 2014 10:38:47 -0600 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> References: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> Message-ID: <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> All, Ozy is still being supported. Ozy works with the current versions of firmware and software on the OpenHPSDR download page (http://openhpsdr.org/download.php). In particular, the current official versions of firmware for Ozy based systems are: PowerSDR_mRX_PS_v3.2.17.0 Ozy v2.7 (included in the PowerSDR_mRX_PS_v3.2.17.0 folder and loads automatically when Ozy is selected as hardware and the initozy11.bat file is edited to point to Ozy_Janus.v27.rbf file) Mercury v3.4 Penelope v1.8 PureSignal is not implemented in any of the Atlas-based systems at the present time so that option in PowerSDR is not available when running Ozy (or Metis). Keep in mind that you may not mix ?old? firmware versions with firmware version that are later than 4May2013 (i.e., Ozy_Janus_v2.5 in the case for Ozy) as a major change for all the Atlas-based boards was made to implement a new I2C bus communications scheme between Ozy(or Metis) and the Mercury/Penelope boards. If you use a version of current firmware in any of the Ozy/Mercury/Penelope boards you must use current firmware in all of the boards (recommended). 73, Joe K5SO 1407170327.0 From getpri at t-online.de Mon Aug 4 10:32:59 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 04 Aug 2014 19:32:59 +0200 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> References: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> Message-ID: <53DFC3CB.1000502@t-online.de> Thank you Joe and all who responded. Best wishes and 73 Georg, DL2KP Am 04.08.2014 18:38, schrieb Joe Martin K5SO: > ***** High Performance Software Defined Radio Discussion List ***** > > > All, > > Ozy is still being supported. Ozy works with the current versions of firmware and software on the OpenHPSDR download page (http://openhpsdr.org/download.php). > > In particular, the current official versions of firmware for Ozy based systems are: > > PowerSDR_mRX_PS_v3.2.17.0 > > Ozy v2.7 (included in the PowerSDR_mRX_PS_v3.2.17.0 folder and loads automatically when Ozy is selected as hardware and the initozy11.bat file is edited to point to Ozy_Janus.v27.rbf file) > > Mercury v3.4 > > Penelope v1.8 > > PureSignal is not implemented in any of the Atlas-based systems at the present time so that option in PowerSDR is not available when running Ozy (or Metis). > > Keep in mind that you may not mix ?old? firmware versions with firmware version that are later than 4May2013 (i.e., Ozy_Janus_v2.5 in the case for Ozy) as a major change for all the Atlas-based boards was made to implement a new I2C bus communications scheme between Ozy(or Metis) and the Mercury/Penelope boards. > > If you use a version of current firmware in any of the Ozy/Mercury/Penelope boards you must use current firmware in all of the boards (recommended). > > 73, Joe K5SO > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- Internet: in progress ********************************************************************** IMPORTANTE/IMPORTANT CONFIDENCIAL/CONFIDENTIALITY Este mensaje ha sido elaborado ?nicamente para uso de la persona o entidad a la que es remitido, ya que puede contener informaci?n personal, confidencial y de acuerdo a ley no puede ser difundido. Si el lector de este mensaje no es el destinatario se?alado, o la persona responsable para entregar el mensaje a quien est? dirigido, advertimos que cualquier divulgaci?n, retransmisi?n o copia de esta comunicaci?n esta estrictamente prohibida. Si usted ha recibido esta comunicaci?n por error, por favor s?rvase informarlo de inmediato al remitente por correo electr?nico o tel?fono y borrar inmediatamente el mensaje original. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail kann vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ********************************************************************** --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com 1407173579.0 From wb4gcs at wb4gcs.org Mon Aug 4 15:02:02 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Mon, 04 Aug 2014 18:02:02 -0400 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> References: <6A96F792B1E64794B89C736F08C5CBA7@dd52f851956584> <1804055C-7A7D-4C8A-83BA-793D8F356E25@valornet.com> Message-ID: <53E002DA.1080004@wb4gcs.org> Joe: I'm a bit confused by the "keep in mind" paragraph. Does this mean there is some hardware version at which the firmware splits? I have an atlas/ozy/janus system that is probably near original hardware from TAPR. Will the latest firmware you mention below run on that system, or is there some version at which that hardware is no longer supported? Thanks & 73, Jim wb4gcs at amsat.org On 8/4/2014 12:38 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > All, > > Ozy is still being supported. Ozy works with the current versions of firmware and software on the OpenHPSDR download page (http://openhpsdr.org/download.php). > > In particular, the current official versions of firmware for Ozy based systems are: > > PowerSDR_mRX_PS_v3.2.17.0 > > Ozy v2.7 (included in the PowerSDR_mRX_PS_v3.2.17.0 folder and loads automatically when Ozy is selected as hardware and the initozy11.bat file is edited to point to Ozy_Janus.v27.rbf file) > > Mercury v3.4 > > Penelope v1.8 > > PureSignal is not implemented in any of the Atlas-based systems at the present time so that option in PowerSDR is not available when running Ozy (or Metis). > > Keep in mind that you may not mix ?old? firmware versions with firmware version that are later than 4May2013 (i.e., Ozy_Janus_v2.5 in the case for Ozy) as a major change for all the Atlas-based boards was made to implement a new I2C bus communications scheme between Ozy(or Metis) and the Mercury/Penelope boards. > > If you use a version of current firmware in any of the Ozy/Mercury/Penelope boards you must use current firmware in all of the boards (recommended). > > 73, Joe K5SO > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1407189722.0 From beford at myfairpoint.net Mon Aug 4 17:31:08 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Mon, 4 Aug 2014 20:31:08 -0400 Subject: [hpsdr] PwrSDR with Ozy Message-ID: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> Jim- The have been no changes in the hardware. Joe's reminder is that if you are using firmware later than 4May13 in one board, you must use firmware later than that date in ALL the boards on the system. This is because some signals were redefined at that time. The hardware hasn't changed, but the purpose of some of the various signal pins did (defined by the firmware, not the hardware). So- don't mix old board firmware and newer firmware in an Atlas-based system. I hope this helps. Bruce/N1RX > Joe: > I'm a bit confused by the "keep in mind" paragraph. Does this mean > there is some hardware version at which the firmware splits? 1407198668.0 From k5so at valornet.com Mon Aug 4 17:39:01 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 4 Aug 2014 18:39:01 -0600 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> References: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> Message-ID: -ditto. Thanks Bruce, I was out today. 73, Joe K5SO On Aug 4, 2014, at 6:31 PM, Bruce Beford wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Jim- > The have been no changes in the hardware. Joe's reminder is that if you are > using firmware later than 4May13 in one board, you must use firmware later > than that date in ALL the boards on the system. This is because some signals > were redefined at that time. The hardware hasn't changed, but the purpose of > some of the various signal pins did (defined by the firmware, not the > hardware). So- don't mix old board firmware and newer firmware in an > Atlas-based system. > I hope this helps. > Bruce/N1RX > >> Joe: >> I'm a bit confused by the "keep in mind" paragraph. Does this mean >> there is some hardware version at which the firmware splits? > > 1407199141.0 From wb4gcs at wb4gcs.org Mon Aug 4 18:10:53 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Mon, 04 Aug 2014 21:10:53 -0400 Subject: [hpsdr] PwrSDR with Ozy In-Reply-To: References: <918B64B8AB5E4F7093C91370CC440F64@HPE250f> Message-ID: <53E02F1D.1070505@wb4gcs.org> Bruce & Joe: Got it, thanks! FYI, I intend to use Janus/Ozy with a 2-slot Atlas I picked up somewhere to interface to a UHFSDR, which is the IF for my microwave stack: 222, 903,1293, 2304, 3446, 5763 and 10368. The last two will be double-conversion to obey the IF >= 0.1 RF rule. 73, Jim wb4gcs at amsat.org On 8/4/2014 8:39 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > -ditto. Thanks Bruce, I was out today. > > 73, Joe K5SO > > On Aug 4, 2014, at 6:31 PM, Bruce Beford wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Jim- >> The have been no changes in the hardware. Joe's reminder is that if you are >> using firmware later than 4May13 in one board, you must use firmware later >> than that date in ALL the boards on the system. This is because some signals >> were redefined at that time. The hardware hasn't changed, but the purpose of >> some of the various signal pins did (defined by the firmware, not the >> hardware). So- don't mix old board firmware and newer firmware in an >> Atlas-based system. >> I hope this helps. >> Bruce/N1RX >> >>> Joe: >>> I'm a bit confused by the "keep in mind" paragraph. Does this mean >>> there is some hardware version at which the firmware splits? >> > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1407201053.0 From carcia at sbcglobal.net Tue Aug 5 08:26:00 2014 From: carcia at sbcglobal.net (FRANCIS CARCIA) Date: Tue, 5 Aug 2014 08:26:00 -0700 Subject: [hpsdr] IMD Message-ID: <1407252360.20359.YahooMailNeo@web184705.mail.ne1.yahoo.com> Hi All, ?As a suffering Giants football fan and a long time chaser of the IMD monster. Congradulations Warren. I will be starting metal work on my QRO SS linear soon now that my slabs of copper have returned from the machine shop. Great Job. Frank WA1GFZ -------------- next part -------------- An HTML attachment was scrubbed... URL: From k2ue at rochester.rr.com Thu Aug 7 15:42:19 2014 From: k2ue at rochester.rr.com (Clyde Washburn) Date: Thu, 7 Aug 2014 18:42:19 -0400 Subject: [hpsdr] Remote Control? Message-ID: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> What is the state of the art in remote control of an OpenHPSDR Tranceiver (such as an Anan) via an internet connection with 1 or 2Mb/s uplink and typical latency? I know OpenHPSDR can be operated via Remote Desktop, but what is the optimal setup for Rx audio to the remote site and Tx audio to the Transceiver, i.e. a full, functioning remote setup? ___________________ Clyde Washburn, K2UE k2ue at ieee.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From n9vv at wowway.com Thu Aug 7 16:11:24 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Thu, 07 Aug 2014 18:11:24 -0500 Subject: [hpsdr] Remote Control? In-Reply-To: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> References: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> Message-ID: <53E4079C.1040203@wowway.com> Hi Clyde, I think the optimal (consultant) answer will cost more than your whole station :-) Here is a list of REMOTE CONTROL programs that are popular. Each claims to be the best. Some have full Audio support: ---------------------------------------------- http://www.remotehams.com/ Any Desk SplashTOP Screen Hero Google Remote Teamviewer Mikogo Parallels Access http://www.dxzone.com/catalog/Contesting/Stations/ (50 entries) http://www.dxzone.com/catalog/Manufacturers/Remote_Control/ (5) http://www.dxzone.com/catalog/Operating_Modes/Remote_Operations/ (9) http://www.dxzone.com/dx6349/internet-remote-base-society.html http://www.dxzone.com/dx13063/remote-controlled-hf-operations.html http://www.dxzone.com/dx24426/remoterig.html UltraVNC TightVNC TinyVNC Skype (for audio) ipSound (discontinued in 2006, but still popular) HPSDR (Android application for Internet Remote for OpenHPSDR written by G0ORX/N6LYT) QtRadio (Win/Lin/MAC remote application for OpenHPSDR written by G0ORX/N6LYT) glSDR - Android QtRadio client with full control written by volunteers for OpenHPSDR ---------------------------------------------- George, K5RIG, and I are currently testing each of these programs to see if any one of them might be suitable. Remote Control of a PC seems to be a very popular topic - and one that has *NOT* been resolved into a manageable set of alternatives. The fellows at RemoteHams.COM have a very attractive setup. So do a dozen others, all at varying prices and kinds of rigs. Flex Radio Systems is going to put Remote Operation on the top of their Developers list this year. They took a show of hands at their Dayton-2014 Banquet and *Remote Operation* was at the top of the list of desired features that their 6000 owners desired. So there is a good list of resources and you can begin your award winning book about "Remote Ham Radio Station Operation" -- or has the ARRL already done that? (hihihi). GL de Ken N9VV On 8/7/2014 5:42 PM, Clyde Washburn wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > What is the state of the art in remote control of an OpenHPSDR > Tranceiver (such as an Anan) via an internet connection with 1 or 2Mb/s > uplink and typical latency? I know OpenHPSDR can be operated via Remote > Desktop, but what is the optimal setup for Rx audio to the remote site > and Tx audio to the Transceiver, i.e. a full, functioning remote setup? > > ___________________ > > Clyde Washburn, K2UE > > k2ue at ieee.org > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1407453084.0 From aa8k73 at gmail.com Thu Aug 7 17:14:16 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Thu, 07 Aug 2014 20:14:16 -0400 Subject: [hpsdr] Remote Control? In-Reply-To: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> References: <00e501cfb290$d8d13de0$8a73b9a0$@rochester.rr.com> Message-ID: <53E41658.9060607@gmail.com> I don't believe that you will be able to transmit CW remotely in the future Clyde. From what I have gleaned about the Generation 2 HPSDR hardware, the telegraph key will be connected to the FPGA on the transmitter board itself as an effort to reduce latency. This is useful if you are physically near the transmitter, but if you have Repetitive Strain Injury ("glass arm") or another disability requiring you use a keyboard instead of wiggling a lever, or want to operate remotely, or to use any type of CW transmitting software, I'm guessing that you would need to tinker some sort of RS-232 type of kludge. On 14-08-07 06:42 PM, Clyde Washburn wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > What is the state of the art in remote control of an OpenHPSDR > Tranceiver (such as an Anan) via an internet connection with 1 > or 2Mb/s uplink and typical latency? I know OpenHPSDR can be > operated via Remote Desktop, but what is the optimal setup for > Rx audio to the remote site and Tx audio to the Transceiver, > i.e. a full, functioning remote setup? > > ___________________ > > Clyde Washburn, K2UE > > k2ue at ieee.org > 1407456856.0 From pa0tbr at mubo.nl Sat Aug 2 13:56:17 2014 From: pa0tbr at mubo.nl (Ton PA0TBR) Date: Sat, 2 Aug 2014 22:56:17 +0200 Subject: [hpsdr] Compile environement for PowerSDR_HPSDR_mRX_PS Message-ID: Hello, Is Visual Studio 2010 Express the correct environment to compile PowerSDR_HPSDR_mRX_PS? Are there any development notes available? 73, Ton PA0TBR -------------- next part -------------- An HTML attachment was scrubbed... URL: From vk5lb at yahoo.com.au Fri Aug 8 07:46:10 2014 From: vk5lb at yahoo.com.au (Dean PROBERT) Date: Fri, 8 Aug 2014 07:46:10 -0700 Subject: [hpsdr] Downloading Mercury 3.4 In-Reply-To: Message-ID: <1407509170.73138.YahooMailBasic@web120405.mail.ne1.yahoo.com> Thanks for the info I successfully downloaded all files listed below except Mercury V3,4, All I saw was the raw code. How can I download the file? ???????????? 1407509170.0 From jeffrie at talktalk.net Fri Aug 8 08:42:28 2014 From: jeffrie at talktalk.net (Jeff Cook) Date: Fri, 8 Aug 2014 16:42:28 +0100 Subject: [hpsdr] Downloading Mercury 3.4 Message-ID: <000001cfb31f$5d4736e0$17d5a4a0$@talktalk.net> Dean, try http://svn.tapr.org/repos_sdr_hpsdr/trunk/Mercury/Source/Mercury_V3.4/ Jeff, G0AFQ. -------------- next part -------------- An HTML attachment was scrubbed... URL: From k2xx at swva.net Fri Aug 8 14:19:01 2014 From: k2xx at swva.net (Joe Giacobello, K2XX) Date: Fri, 08 Aug 2014 17:19:01 -0400 Subject: [hpsdr] Hermes Breakout Brd 2-pin Header Message-ID: <53E53EC5.60209@swva.net> In procrastinating my assembly of the breakout board, I seemed to have lost one of the 2-pin PCB headers. If someone has a spare and can put it in an envelope and mail to my CBA, I'd be happy to reimburse by PayPal or whatever payment method works. Thanks for your help. 73, Joe K2XX 1407532741.0 From aa8k73 at gmail.com Fri Aug 8 20:33:06 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 08 Aug 2014 23:33:06 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/09 Message-ID: <53E59672.6040100@gmail.com> The 9/Aug TeamSpeak mp3 (51 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3510 > or < http://www.hamsdr.com/dnld.aspx > Session text follows <20:41:19> *** You are now talking in channel: "OpenHPSDR" <21:03:28> "Ken N9VV": Nvida Jetson TK1 - Xwindows remote to Windows PC: https://www.youtube.com/watch?v=Z64z_R7MSMU <21:11:12> "Bill - KD5TFD": Yes yes .. TAPR DCC beginning of Sept <21:15:52> "Rick - VE3MM": Rob, Here is the digikey part number for the Hermes extension cable 'A3AKB-1018G-ND'. <21:16:42> "Bill - KD5TFD": AQRP charts on STM32F4 based sdr: https://dl.dropboxusercontent.com/u/14377548/2014%20SummerFest_1.pdf <21:17:04> "Bill - KD5TFD": and: http://stm32-sdr.com/ <21:17:28> "Rob - VE3EW": thanks Rick <21:20:41> "Phil-VK6PH": http://www.ab4oj.com/sdr/apache/anan100d200d_notes.pdf <21:20:45> "Bill - KD5TFD": works ok here <21:21:11> "Ken N9VV": http://www.ab4oj.com/sdr/apache/anan100d200d_notes.pdf FB Here <21:21:38> "Bill - KD5TFD": IE? <21:21:39> "Bill - KD5TFD": IE? <21:21:46> "Bill - KD5TFD": Use a real real browser1 <21:21:49> "Bill - KD5TFD": Use a real real browser! <21:26:37> "Ken N9VV": God! that Keying Envelope looks *GREAT* <21:42:05> "Rick - VE3MM": 73 guys see you next week <21:45:38> "Bill - KD5TFD": sarcasm <22:07:16> "Bill - KD5TFD": so do macs <22:07:20> "Bill - KD5TFD": and linuii's <22:08:02> "Bill - KD5TFD": never do the fix my pc stuff imho 1407555186.0 From vk6vz at arach.net.au Sat Aug 9 07:42:26 2014 From: vk6vz at arach.net.au (Steve Ireland) Date: Sat, 9 Aug 2014 22:42:26 +0800 Subject: [hpsdr] For Sale: Munin PA kit and Tmate 2 USB SDR Control Console Message-ID: <4F58396271064EC8B49A5020427EA8F8@StevesHPpcPC> G?day I have for sale an HPSDR Munin Power Amplifier kit compiled by Don K3DLW and a WoodBox Radio Tmate2 USB SDR Control Console in ?as new? condition. The Tmate2 has been used with OpenHPSDR W5WC v2.2.12 and all its functionality was available with this software except for the wattmeter. The Munin Power Amplifier Kit is for sale at $200 Australian and has not been opened. The WoodBox Radio Tmate2 is 15 months old, cost 260 Euros (approx. $375 Australian) and is for sale at $300 Australian. Postage on both items will be extra. If you are interested in either item, please email me. Thank you. Vy 73 Steve, VK6VZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ad0es at ad0es.net Sat Aug 9 08:26:15 2014 From: ad0es at ad0es.net (AD0ES) Date: Sat, 9 Aug 2014 09:26:15 -0600 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: Message-ID: Hi, I wrote earlier about my issues getting a metis/mercury working. Finally had success last nite! For the record, I found the following: The mercury as shipped from TAPR had unknown/non-working firmware installed: > Mercury Software version: 255 (0xFF) I upgraded metis to 2.9 and mercury to 3.4. I tried 4 different software packages, only one works. Each was built from sources obtained from their motherload several weeks ago: ghpsdr: seg-faults on startup. ghpsdr3: works. ghpsdr3-Qt: dspserver seg-faults on startup. ghpsdr3-alex: runs, but is "deaf" <<< this was the version I did most of my early testing with Using ubuntu 64-bit 14.04.1 I am going after the seg-faults next, any wisdom on this issue gladly accepted... Steve AD0ES On Jul 23, 2014, at 9:47 AM, AD0ES wrote: > Using ghpsdr3-alex. > > ------------------- > Start hpsdr-server: > /usr/local/bin/hpsdr-server --metis --interface eth0 --10mhzsource mercury --122.88mhzsource mercury > > ... > > Mercury Software version: 255 (0xFF) 1407597975.0 From k2xx at swva.net Sat Aug 9 08:46:07 2014 From: k2xx at swva.net (Joe Giacobello, K2XX) Date: Sat, 09 Aug 2014 11:46:07 -0400 Subject: [hpsdr] Hermes Breakout Brd 2-pin Header (Got it!) Message-ID: <53E6423F.90801@swva.net> K6GGO kindly offered to send me the part. Many thanks, Joe K2XX In procrastinating my assembly of the breakout board, I seemed to have lost one of the 2-pin PCB headers. If someone has a spare and can put it in an envelope and mail to my CBA, I'd be happy to reimburse by PayPal or whatever payment method works. Thanks for your help. 73, Joe K2XX 1407599167.0 From cmwalker at mweb.co.za Sat Aug 9 21:40:10 2014 From: cmwalker at mweb.co.za (Conrad Walker) Date: Sun, 10 Aug 2014 06:40:10 +0200 Subject: [hpsdr] PowerSDR & OZY/Mercury/Penelope updating Message-ID: <002c01cfb455$2c0e2ca0$842a85e0$@co.za> Hello all I decided to update my Ozy/Mercury/Penelope HPSDR on WinXP to v2.7/v3.4/v1.8 with PowerSDR v3.2.17.0. Try as I might, I could not flash Mercury with v3.4 firmware via Ozy with USB-Blaster & either Quartus 9.1, 10.1, 12.1 or 13.0. Quartus 9.10 &10.1 gave an error "file Mercury-v3.4.jic corrupted" - unknown argument "Mercury-3.4.cdf", refer to help for legal arguments. Quartus 12.1 and 13.0 gave a "device not ready" error. I was able to flash Mercury v3.3 with Quartus 9.1 & 10.1, and all Quartus versions successfully flashed Penelope v1.8. I was able to run PowerSDR v3.2.17.0 with Mercury v3.3 and Penny v1.7 but found that the CW setup option to use Ozy/Hermes for CW keying no longer exists, and so can no longer run CW with my present setup, My earlier PowerSDR installation worked fine. Any ideas on sorting this out would be most appreciated. 73, Conrad Walker ZS6BQQ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.montefusco at gmail.com Sun Aug 10 11:03:11 2014 From: andrea.montefusco at gmail.com (andrea montefusco) Date: Sun, 10 Aug 2014 20:03:11 +0200 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> Message-ID: On Sun, Aug 10, 2014 at 3:57 PM, AD0ES wrote: > I am aware of cuSDR, but a quick google didn't find the motherload for linux src, any links? As per http://openhpsdr.org/download.php the source are foud in http://svn.tapr.org/repos_sdr_hpsdr/trunk/DL3HVH/cuSDR64/ it requires Qt 4.8. 1407693791.0 From lu9cbl at gmail.com Sun Aug 10 11:16:00 2014 From: lu9cbl at gmail.com (lu9cbl at gmail.com) Date: Sun, 10 Aug 2014 15:16:00 -0300 Subject: [hpsdr] Starting with HPSDR from Argentina Message-ID: <53E7B6E0.30606@gmail.com> Hi to all... if i want to start with HPSDR, only with the "Atlas Bus", "Mercury Receiver" and the filters "Alex RX" can it works?? or i?m need another "module" for example "Comunication (Ozy, Magister, Metis)"??? Here in Argentina it?s very difficult to buy international ?tems, because we have several filters for import materials... so maybe i can buy the PCBs and make the boards with local components, or buy only the important componentes. I Have a friend that will be going to USA the next month, so he can bring it to me in his briefcase. Thanks in Advance and sorry for my poor english, i hope you can undesrtand me. Mati LU9CBL --- Este mensaje no contiene virus ni malware porque la protecci?n de avast! Antivirus est? activa. http://www.avast.com 1407694560.0 From wulf at ping.net.au Sun Aug 10 15:16:09 2014 From: wulf at ping.net.au (Berndt Josef Wulf) Date: Mon, 11 Aug 2014 07:46:09 +0930 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> Message-ID: <1407708969.5462.23.camel@Barossa> G'day, A modified version of cuSDR can be downloaded from http://www.ping.net.au/20140126_cuSDR64src.tar.gz It requires QT5 and may not work with the current firmware change, so your mileage may wary. 73, Berndt VK5ABN On Sun, 2014-08-10 at 20:03 +0200, andrea montefusco wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > On Sun, Aug 10, 2014 at 3:57 PM, AD0ES wrote: > > I am aware of cuSDR, but a quick google didn't find the motherload for linux src, any links? > > As per http://openhpsdr.org/download.php the source are foud in > > http://svn.tapr.org/repos_sdr_hpsdr/trunk/DL3HVH/cuSDR64/ > > it requires Qt 4.8. > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1407708969.0 From k5so at valornet.com Sun Aug 10 17:52:18 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 10 Aug 2014 18:52:18 -0600 Subject: [hpsdr] Starting with HPSDR from Argentina In-Reply-To: <53E7B6E0.30606@gmail.com> References: <53E7B6E0.30606@gmail.com> Message-ID: <7FC10CDE-148A-426A-AE9C-7935A4EB8C25@valornet.com> Your English is fine, Mati; no problem. Congratulations on thinking of putting together an Atlas-based HPSDR system. In addition to the Atlas bus, Mercury board, and Alex RX filter you will need a board to communicate with your computer; a Metis (ethernet) board or an Ozy (USB) or a Magister (USB); only one of those three computer comm boards, not all three. I recommend Metis, personally, as the ethernet connection is much superior to the USB methods, especially for high data rates that are necessary for wide bandwidths, but Ozy or Magister will work if you decide to use one of them instead. Also, if you use only the Alex RX filter you will have only high pass filtering on your receiver. If you wish to have bandpass filtering you will also need to use the Alex TX filter with the Alex RX filter. The Alex TX filter board provides low pass filtering. Together the Alex RX and Alex TX provide bandpass filtering. Of course, you can run simply a Mercury receiver and a Metis (or Ozy or Magister) on your Atlas bus to have a functional RX radio, without any Alex filters at all, if you wish to try that configuration first before purchasing Alex filter boards. The Alex filters are excellent filter boards and certainly enhance the operations, especially if you are in a location with large out-of-band signals present. I use both TX and RX Alex filters here and find them to be extremely useful to keep from overloading the Mercury receiver when large out-of-band signals are present. Good luck! 73, Joe K5SO On Aug 10, 2014, at 12:16 PM, lu9cbl at gmail.com wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi to all... if i want to start with HPSDR, only with the "Atlas Bus", "Mercury Receiver" and the filters "Alex RX" can it works?? or i?m need another "module" for example "Comunication (Ozy, Magister, Metis)"??? > > Here in Argentina it?s very difficult to buy international ?tems, because we have several filters for import materials... so maybe i can buy the PCBs and make the boards with local components, or buy only the important componentes. I Have a friend that will be going to USA the next month, so he can bring it to me in his briefcase. > > Thanks in Advance and sorry for my poor english, i hope you can undesrtand me. > Mati LU9CBL > > --- > Este mensaje no contiene virus ni malware porque la protecci?n de avast! Antivirus est? activa. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1407718338.0 From douglas.adams at me.com Mon Aug 11 04:45:39 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 07:45:39 -0400 Subject: [hpsdr] Radio (Board) Identification Message-ID: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> I would like to propose a small change to the firmware of all of the OpenHPSDR-derived radios. The purpose of this change would be to make the firmware update process more automatic and foolproof. If you look in Metis- How it works_V1.31 you will see that the Discovery packet returns the following: The payload of the UDP/IP reply frame is as follows: <0xEFFE>< Metis MAC Address><49 bytes of 0x00> where Board_ID = 1 byte, 0x00 = Metis, 0x01 = Hermes, 0x02 = Griffin, 0x04 = Angelia, 0x05 = Orion Currently the Board_ID field (one byte) is not very informative. If it says I have a Hermes (0x01) is it a TAPR Hermes, an ANAN-100, an ANAN-100B, an ANAN-100D, etc. Couldn't we use the 8 bits (256 possibilities) in this field to be more specific about the radio? Perhaps to be backward compatible we could reserve the least significant 4 bits for Board ID and use the most significant four bits for a Sub ID indicating which variant of the Board ID is present. If we coupled this change with a "gentlemen's agreement" to name all firmware files in some recognizable way, something like RadioName_vN.M.rbf ( e.g. ANAN100B_v2.4.rbf ) then it would be possible to write a programmer application that would only show you firmware choices appropriate for the radio you are trying to program. The current arrangement seems uninformative and error prone. 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From ad0es at ad0es.net Mon Aug 11 06:33:44 2014 From: ad0es at ad0es.net (AD0ES) Date: Mon, 11 Aug 2014 07:33:44 -0600 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: Message-ID: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> Hi, Using --hermes instead of --metis does indeed cure the deafness, thanx! So for the record, at this point all 4 programs are working: ghpsdr ghpsdr3 ghpsdr3-Qt ghpsdr3-alex Note that I had to make minor changes to get several of them to compile under Ubuntu 14.04.1 (trusty). Mostly issues of header file locations being moved since the last distro. Steve AD0ES On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES wrote: > >> ghpsdr3-alex: runs, but is "deaf" <<< this was the version I did most of my early testing with > > Steve, > please start the hpsdr-server with --hermes instead of --metis and > report if this cure the issue. 1407764024.0 From kb3omm at gmail.com Mon Aug 11 07:02:59 2014 From: kb3omm at gmail.com (kb3omm) Date: Mon, 11 Aug 2014 10:02:59 -0400 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> Message-ID: Steve, This is great news. Could you email out the changes you made to get each of the programs to build and run, to aid those like myself who cant program but can follow instructions. I have tried previously to get John's three programs to build on newer versions of Qt and Linux without success. Though, ghpsdr3-alex and cuSDR run fine and use them every day. Hermes, Mint 16, Qt4 and 5 73, Kevin On Mon, Aug 11, 2014 at 9:33 AM, AD0ES wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi, > > Using --hermes instead of --metis does indeed cure the deafness, thanx! > > So for the record, at this point all 4 programs are working: > ghpsdr > ghpsdr3 > ghpsdr3-Qt > ghpsdr3-alex > > Note that I had to make minor changes to get several of them to compile > under Ubuntu 14.04.1 (trusty). Mostly issues > of header file locations being moved since the last distro. > > Steve AD0ES > > On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: > > > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES wrote: > > > >> ghpsdr3-alex: runs, but is "deaf" <<< this was the version I > did most of my early testing with > > > > Steve, > > please start the hpsdr-server with --hermes instead of --metis and > > report if this cure the issue. > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 07:12:51 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 08:12:51 -0600 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> Message-ID: <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> Hi Doug, Interesting proposal that deserves some thought. I don?t disagree that our present system is not a perfect arrangement. Keep in mind however that the Board ID is not the only ID parameter ID that is passed in the packets, the actual firmware version is also passed in the packets in a different byte, so that in itself gives more information than you imply, I believe. The board ID is currently used, among other uses perhaps, by the HPSDR Programmer to determine how long to make the time out limit for the EEPROM erase process; some FPGAs are small (e.g., Metis, Mercury, Penny(Lane), Hermes) and erase quickly compared to the larger (Angelia and Orion) FPGAs that take a while to erase. Dave KV0S didn?t think (and I agree) that it was necessary, nor beneficial, to use a long time out delay for erasing FPGAs that didn?t need one. The current ID method works fine for that purpose and needs no additional expansion. While I certainly appreciate that we might want to specify which specific board type is in use (which we do already in a general sense with the current coarse board ID value) the firmware is used in many cases in a variety of hardware configurations of the same board type so it would not be possible for the firmware developer to write the more detailed ID number into the firmware without knowing ahead of time which of the several configurations for the board type is going to be used with the firmware. In the case of Angelia, as one example, the firmware can be used in any radio that uses the Angelia board such as the ANAN-100D or a barefoot Angelia, or an Angelia with an external PA, or with an Angelia with Alex filters, etc. In your suggestion it would seem that all of those different configurations should ideally have a different board ID value written into the firmware. The firmware design would be identical for those units but your suggested approach would seek to use a different board ?ID? for each of them depending upon how the user wanted to use the Angelia board, which the firmware writer would not know. Having a different board ID for each possible board configuration, and thus a different firmware version for each possible configuration, would lead to many versions of Angelia (etc) firmware for a given firmware design needing to be posted for each release and that in itself would undoubtedly prove to be confusing to the users, in my opinion. I haven?t thought through your suggestion completely but these points came immediately to my mind upon reading your message. Maybe others have comments and suggestions that are constructive for this discussion. Thanks for your thoughts on how we might improve things! Perhaps you have already thought through how to address issues such as these. I?m all for whatever makes the mose sense! 73, Joe K5SO On Aug 11, 2014, at 5:45 AM, Doug Adams wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I would like to propose a small change to the firmware of all of the OpenHPSDR-derived radios. The purpose of this change would be to make the firmware update process more automatic and foolproof. > > If you look in Metis- How it works_V1.31 you will see that the Discovery packet returns the following: > The payload of the UDP/IP reply frame is as follows: > <0xEFFE>< Metis MAC Address><49 bytes of 0x00> > > where > > Board_ID = 1 byte, 0x00 = Metis, 0x01 = Hermes, 0x02 = Griffin, 0x04 = Angelia, 0x05 = Orion > > Currently the Board_ID field (one byte) is not very informative. If it says I have a Hermes (0x01) is it a TAPR Hermes, an ANAN-100, an ANAN-100B, an ANAN-100D, etc. Couldn't we use the 8 bits (256 possibilities) in this field to be more specific about the radio? > > Perhaps to be backward compatible we could reserve the least significant 4 bits for Board ID and use the most significant four bits for a Sub ID indicating which variant of the Board ID is present. > > If we coupled this change with a "gentlemen's agreement" to name all firmware files in some recognizable way, something like RadioName_vN.M.rbf ( e.g. ANAN100B_v2.4.rbf ) then it would be possible to write a programmer application that would only show you firmware choices appropriate for the radio you are trying to program. > > The current arrangement seems uninformative and error prone. > > 73?s > Doug - K3TZR > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wully at bluewin.ch Mon Aug 11 09:03:01 2014 From: wully at bluewin.ch (wully) Date: Mon, 11 Aug 2014 18:03:01 +0200 Subject: [hpsdr] CC-Byte0 from fpga to pc Message-ID: <53E8E935.4090808@bluewin.ch> Hi In the Comand-and-Control-Byte 0 from FPGA to PC there are 3 Bits PTT, Dash and Dot. I would like to use at least one of these bits to control an activity. But I don't know, how these bits are fed. From the schematics of METIS and fpga-code I think that Pins 6,7 and 8 on the DB9 connector should be mapped to these (debounced) Bits, but grounding these does not show an effect on the CC-Byte 0. Hardware: Metis (fpga V2.1) Penelope (fpga 1.7) Mercury (fpga 3.3) 1) Which hardware- bits control the Bits 0..2 of CCbyte0 when using the above hardware? 2) Which hardware- bits control if I use Magister instead of Metis (IN0, IN1 and IN2 are also present there). Thank you for your information. 73, hb9epu 1407772981.0 From g3vbv at blueyonder.co.uk Mon Aug 11 09:07:25 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 11 Aug 2014 17:07:25 +0100 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> Message-ID: <53E8EA3D.9060807@blueyonder.co.uk> I modified GHPSDR3-Qt/FULL/KV0S/KV0S.pro, adding the Qt include PATHS INCLUDEPATH += . \ /usr/include/QtMultimedia /usr/include/QtNetwork /usr/include/QtXml \ ghpsdr3/DRadio \ griffin/griffinID \ Missing file frequencysender.h:- IQt-Radio-Programs/QtHPSDRServer/client -I. -I. -o receivethread.o hpsdr-programmers/Programmer/receivethread.cpp In file included from hpsdr-programmers/Programmer/receivethread.cpp:37:0: ghpsdr3/DRadio/mainwindow.h:5:29: fatal error: frequencysender.h: No such file or directory #include "frequencysender.h" ^ compilation terminated. make: *** [receivethread.o] Error 1 73 ... Sid. On 11/08/14 15:02, kb3omm wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > Steve, This is great news. > > Could you email out the changes you made to get each of the programs > to build and run, to aid those like myself who cant program but can > follow instructions. > > I have tried previously to get John's three programs to build on newer > versions of Qt and Linux without success. > > Though, ghpsdr3-alex and cuSDR run fine and use them every day. > > Hermes, Mint 16, Qt4 and 5 > > 73, Kevin > > > On Mon, Aug 11, 2014 at 9:33 AM, AD0ES > wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi, > > Using --hermes instead of --metis does indeed cure the deafness, > thanx! > > So for the record, at this point all 4 programs are working: > ghpsdr > ghpsdr3 > ghpsdr3-Qt > ghpsdr3-alex > > Note that I had to make minor changes to get several of them to > compile under Ubuntu 14.04.1 (trusty). ? Mostly issues > of header file locations being moved since the last distro. > > Steve ? AD0ES > > On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: > > > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES > wrote: > > > >> ? ? ? ? ghpsdr3-alex: ? runs, but is "deaf" <<< this was > the version I did most of my early testing with > > > > Steve, > > please start the hpsdr-server with --hermes instead of --metis and > > report if this cure the issue. > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 09:38:40 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 10:38:40 -0600 Subject: [hpsdr] PowerSDR & OZY/Mercury/Penelope updating In-Reply-To: <002c01cfb455$2c0e2ca0$842a85e0$@co.za> References: <002c01cfb455$2c0e2ca0$842a85e0$@co.za> Message-ID: <6282414A-39D6-4B4A-B895-F74A508BACD3@valornet.com> Hi Conrad, I haven?t seen any response on the list for your inquiry so I?ll respond. I wonder if you are using the current USBBinaries-Blaster folder? It can be found at http://svn.tapr.org/repos_sdr_hpsdr/trunk/USBBlaster-Binaries/ If not, please get the latest folder and give those files a try. Even if you do already have the latest USBBlaster-Binaries folder the message below seems to indicate that the files may be corrupted somehow. Therefore, in this case too, I?d download a fresh copy of the USBBlaster-Binaries folder and try them to see if that will work for you. I just checked the current USBBlaster-Binaries/Program-Mercury-EPCS16.bat file in the USBBlaster-Binaries folder to verify that it has options for the current Altera Quartus II v13.0 version and Mercury_v3.4; it does, so it should work I would think. 73, Joe K5SO On Aug 9, 2014, at 10:40 PM, Conrad Walker wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hello all > > I decided to update my Ozy/Mercury/Penelope HPSDR on WinXP to v2.7/v3.4/v1.8 with PowerSDR v3.2.17.0. > > Try as I might, I could not flash Mercury with v3.4 firmware via Ozy with USB-Blaster & either Quartus 9.1, 10.1, 12.1 or 13.0. Quartus 9.10 &10.1 gave an error "file Mercury-v3.4.jic corrupted" - unknown argument "Mercury-3.4.cdf", refer to help for legal arguments. Quartus 12.1 and 13.0 gave a "device not ready" error. I was able to flash Mercury v3.3 with Quartus 9.1 & 10.1, and all Quartus versions successfully flashed Penelope v1.8. > > I was able to run PowerSDR v3.2.17.0 with Mercury v3.3 and Penny v1.7 but found that the CW setup option to use Ozy/Hermes for CW keying no longer exists, and so can no longer run CW with my present setup, My earlier PowerSDR installation worked fine. > > Any ideas on sorting this out would be most appreciated. > > 73, > > Conrad Walker ZS6BQQ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wully at bluewin.ch Mon Aug 11 09:44:50 2014 From: wully at bluewin.ch (wully) Date: Mon, 11 Aug 2014 18:44:50 +0200 Subject: [hpsdr] CC-Byte0 from fpga to pc In-Reply-To: <53E8E935.4090808@bluewin.ch> References: <53E8E935.4090808@bluewin.ch> Message-ID: <53E8F302.2070501@bluewin.ch> Hi I have checked the software and found an error in my code: the ccbyte0 brings the IN0,IN1,IN2-States from all boards, that support these. 73, hb9epu On 11.08.2014 18:03, wully wrote: > Hi > > In the Comand-and-Control-Byte 0 from FPGA to PC there are 3 Bits PTT, > Dash and Dot. > > I would like to use at least one of these bits to control an activity. > But I don't know, how these bits are fed. > From the schematics of METIS and fpga-code I think that Pins 6,7 and 8 > on the DB9 connector should be mapped to these (debounced) Bits, > but grounding these does not show an effect on the CC-Byte 0. > > Hardware: > Metis (fpga V2.1) > Penelope (fpga 1.7) > Mercury (fpga 3.3) > > 1) Which hardware- bits control the Bits 0..2 of CCbyte0 when using > the above hardware? > 2) Which hardware- bits control if I use Magister instead of Metis > (IN0, IN1 and IN2 are also present there). > > Thank you for your information. > > 73, hb9epu > > > > 1407775490.0 From douglas.adams at me.com Mon Aug 11 10:00:50 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 13:00:50 -0400 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> Message-ID: Joe, Thank you for your comments. Does the firmware file contain the byte representing the Device ID or is it somehow derived by the firmware from the hardware of the board? I would like to be able to prevent (or maybe just warn) a user from selecting an inappropriate firmware file for their Radio. With the current Board ID I can identify the "sub-type" of the Radio (i.e. Metis, Hermes, Angelia, etc). If the firmware file contains the Device ID (maybe someone can tell me how to find that byte in the firmware file), I could compare that to the Device ID of the Radio. Matching those would get me part way to my intent. I'm in the process of adding Firmware Programming into my own SDR app (on a Mac). If you can picture it, I have two lists on screen; a list of the Radios my app can see on the networks attached to the Mac and a list of the Firmware files it can find at various places on the Mac. I expect the user to select a Radio from the first list and a Firmware file from the second list at which point the Erase & Program button is enabled. The question I've been unable to answer is; how to know that I am about to program my Radio with a Firmware version that is somehow inappropriate? There is another layer to Radio (not Board) identification. As you point out, any one firmware file might be used in multiple Radios. Unfortunately, two Radios with the same Board ID might require different firmware. You also mentioned that the firmware version is reported in the protocol. I agree however I believe some versions are being distinguished by placing a letter after the version (e.g. Hermes v2.9b) and I don't believe the suffix is retained or reported back. As far as naming the firmware files goes, each of us can do that ourselves after downloading them but it would be nice if there was an agreed upon naming scheme being used by the creators of the files. It might avoid some errors. Partly my motivation is simply "getting it right" but partly it's because I also see entries in this list where someone has gotten the wrong firmware installed. On Aug 11, 2014, at 10:12 AM, Joe Martin K5SO wrote: > Hi Doug, > > Interesting proposal that deserves some thought. I don?t disagree that our present system is not a perfect arrangement. > > Keep in mind however that the Board ID is not the only ID parameter ID that is passed in the packets, the actual firmware version is also passed in the packets in a different byte > ....... > > While I certainly appreciate that we might want to specify which specific board type is in use (which we do already in a general sense with the current coarse board ID value) the firmware is used in many cases in a variety of hardware configurations > ....... > > 73, Joe K5SO > 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 10:15:38 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 11:15:38 -0600 Subject: [hpsdr] CC-Byte0 from fpga to pc In-Reply-To: <53E8F302.2070501@bluewin.ch> References: <53E8E935.4090808@bluewin.ch> <53E8F302.2070501@bluewin.ch> Message-ID: Okay, very good. I just checked the behavior of bit 2 in the C0 command bytes coming from Metis, using current firmware in all boards, and it responds fine to the DB9 input pin grounding for DASH. I don?t know why you?d want to use old firmware/software but maybe you have a reason to do so. I did not take time to load old version of firmware for these tests. Current firmware is: Metis_v2.9 Mercury_v3.4 Penelope_v1.8 Current software for PSDR is: PowerSDR_mRX_PS_v3.1.17.0 Thanks for updating your situation! 73, Joe K5SO On Aug 11, 2014, at 10:44 AM, wully wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > I have checked the software and found an error in my code: the ccbyte0 brings the IN0,IN1,IN2-States from all boards, that support these. > > 73, hb9epu > > > On 11.08.2014 18:03, wully wrote: >> Hi >> >> In the Comand-and-Control-Byte 0 from FPGA to PC there are 3 Bits PTT, Dash and Dot. >> >> I would like to use at least one of these bits to control an activity. But I don't know, how these bits are fed. >> From the schematics of METIS and fpga-code I think that Pins 6,7 and 8 on the DB9 connector should be mapped to these (debounced) Bits, >> but grounding these does not show an effect on the CC-Byte 0. >> >> Hardware: >> Metis (fpga V2.1) >> Penelope (fpga 1.7) >> Mercury (fpga 3.3) >> >> 1) Which hardware- bits control the Bits 0..2 of CCbyte0 when using the above hardware? >> 2) Which hardware- bits control if I use Magister instead of Metis (IN0, IN1 and IN2 are also present there). >> >> Thank you for your information. >> >> 73, hb9epu >> 1407777338.0 From kb3omm at gmail.com Mon Aug 11 10:41:31 2014 From: kb3omm at gmail.com (kb3omm) Date: Mon, 11 Aug 2014 13:41:31 -0400 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <53E8EA3D.9060807@blueyonder.co.uk> References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> <53E8EA3D.9060807@blueyonder.co.uk> Message-ID: Steve, Sid, Thanks for your notes. I will try these and report back 73, Kevin On Mon, Aug 11, 2014 at 12:07 PM, Sid Boyce wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > I modified GHPSDR3-Qt/FULL/KV0S/KV0S.pro, adding the Qt include PATHS > INCLUDEPATH += . \ > /usr/include/QtMultimedia /usr/include/QtNetwork > /usr/include/QtXml \ > ghpsdr3/DRadio \ > griffin/griffinID \ > > Missing file frequencysender.h:- > IQt-Radio-Programs/QtHPSDRServer/client -I. -I. -o receivethread.o > hpsdr-programmers/Programmer/receivethread.cpp > In file included from hpsdr-programmers/Programmer/receivethread.cpp:37:0: > ghpsdr3/DRadio/mainwindow.h:5:29: fatal error: frequencysender.h: No such > file or directory > #include "frequencysender.h" > ^ > compilation terminated. > make: *** [receivethread.o] Error 1 > 73 ... Sid. > > On 11/08/14 15:02, kb3omm wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > > > > Steve, This is great news. > > Could you email out the changes you made to get each of the programs to > build and run, to aid those like myself who cant program but can follow > instructions. > > I have tried previously to get John's three programs to build on newer > versions of Qt and Linux without success. > > Though, ghpsdr3-alex and cuSDR run fine and use them every day. > > Hermes, Mint 16, Qt4 and 5 > > 73, Kevin > > > On Mon, Aug 11, 2014 at 9:33 AM, AD0ES wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi, >> >> Using --hermes instead of --metis does indeed cure the deafness, thanx! >> >> So for the record, at this point all 4 programs are working: >> ghpsdr >> ghpsdr3 >> ghpsdr3-Qt >> ghpsdr3-alex >> >> Note that I had to make minor changes to get several of them to compile >> under Ubuntu 14.04.1 (trusty). ? Mostly issues >> of header file locations being moved since the last distro. >> >> Steve ? AD0ES >> >> On Aug 10, 2014, at 3:49 AM, andrea montefusco wrote: >> >> > On Sat, Aug 9, 2014 at 5:26 PM, AD0ES wrote: >> > >> >> ? ? ? ? ghpsdr3-alex: ? runs, but is "deaf" <<< this was the >> version I did most of my early testing with >> > >> > Steve, >> > please start the hpsdr-server with --hermes instead of --metis and >> > report if this cure the issue. >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > -- > 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 > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 11 11:15:47 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 12:15:47 -0600 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> Message-ID: Doug, RR, understood; but I don?t entirely agree with your assessment of the present situation. Let me respond to each of the issues to which I refer: 1) Answering your question: Yes, the firmware Verilog design contains the DEVICE ID number in the Verilog code itself; it?s coded into the ethernet packets directly. For example, the hardware ID value for Angelia is hardcoded in the Angelia Verilog design into line1059 of the TX_MAC module in the Verilog design. It?s done similarly, if not identically, in the Verilog firmware designs for all the other HPSDR and ANAN-series boards. 2) I see what it is that you are trying to accomplish and it?s an admirable goal I think. It seems to me (with one exception which I will mention next) that the current hardware ID scheme works just fine for identifying the hardware to match with firmware. I am not aware of any firmware named for a hardware board that does not work in that board, regardless of the configuration of the board (the exception I mentioned notwithstanding). Namely, the hardware ID specifies whether the board is a Metis, Hermes, Griffin, Angelia, or Orion. The user should be aware, for example, which board his radio uses and therefore be able to match the board with the necessary firmware since the firmware filename includes the board name with which it is intended to be used. 3) The exception I mention above has to do with the minor difference in Apache Labs versions of firmware that are labeled ?b? suffix, in which the switch point for 10m filters is different from radios using Alex filters. The operational effect of not using a ?b? version in an ANAN radio that has the PA filters is perhaps a bit lower maximum output power on 10m; that?s it. Otherwise the firmware will work just fine. 4) I agree with you that labeling firmware versions with a ?b? suffix is not a good idea at all because the firmware version reporting protocol within firmware does not allow for letters in the firmware version numbers. In my opinion, an entirely new firmware version number (using numbers exclusively, no sub-letters) should be used, even for that small distinction of the 10m filter switch point. I always avoid using letter suffix nomenclature in released firmware versions, because there is no way to distinguish those ?modified? versions from the original versions by looking at the version numbers being reported by the firmware. I much prefer to use an entirely different firmware version number which is acceptable in the current firmware version number protocol (no letters) and easily distinguishable from anything else by simply looking at the firmware version number that is reported by the firmware. With regard to loading the wrong firmware, if someone loads Metis code into Angelia, as one example, there really is no excuse for doing it as the Metis firmware has the ?Metis? name in the firmware filename. It?s always a recoverable event in any case, even if it happens. Granted you must use a blaster cable to recover but that?s the penalty you SHOULD have to pay for not reading the name, in my view. Next time you will read it. Further, quite simply, if you own an ANAN radio and don?t even know what major board type the radio has in it (Hermes, Angelia, or Orion) you likely are not well suited to be a user of that radio, as you?re going to have tremendous difficulties operating the thing and updating its firmware later on; my personal opion, of course. I understand your desire to make your code bulletproof against ignorance, and I applaud the attempt, but I think we can go overboard in that area. There are some people who are simply not well suited to using SDR, as I have come to appreciate. I used to think otherwise but sadly now I don?t. These are complex, high-performance radios and they need marginally compentent users at least in order to be able to realize the advantages that they can offer. Again, my opion. You?re all welcome to have a different opinion, if you wish. 73, Joe K5SO 1407780947.0 From douglas.adams at me.com Mon Aug 11 11:31:54 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 14:31:54 -0400 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> Message-ID: <5C402B1B-058D-4861-A53C-B46863D74269@me.com> Joe (et all), Well stated, let me summarize my take away. 1. If I match the name in the firmware file name (e.g. "Hermes", "Metis", "Angelia") with the Board ID from my Radio (translated to the appropriate string) I will never load a non-operative firmware (it may have minor issues such as the filter control but it will work). 2. We should suggest to those who create firmware files that they only use numbered versions (i.e. no suffixes). I can live with #1, I'll implement it in my code as a Warning (to keep me from doing something dumb, I don't own a Blaster, yet). I'm not sure how we get people to comply with #2. On Aug 11, 2014, at 2:15 PM, Joe Martin K5SO wrote: > Doug, > > RR, understood; but I don?t entirely agree with your assessment of the present situation. Let me respond to each of the issues to which I refer: > > .... > These are complex, high-performance radios and they need marginally compentent users at least in order to be able to realize the advantages that they can offer. Again, my opion. You?re all welcome to have a different opinion, if you wish. > > 73, Joe K5SO > > 73?s Doug - K3TZR 1407781914.0 From k5so at valornet.com Mon Aug 11 11:46:59 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 11 Aug 2014 12:46:59 -0600 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: <5C402B1B-058D-4861-A53C-B46863D74269@me.com> References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> <7EFDF0B8-B7E5-4929-80B0-2F0A7B9B51B1@me.com> <5C402B1B-058D-4861-A53C-B46863D74269@me.com> Message-ID: <87FDB69E-648D-4E93-953D-89C99190F44A@valornet.com> Doug, Yes. I think #2 will take care of itself given the amount of angst it has caused already, hihi. We learn as we go. 73, Joe K5SO On Aug 11, 2014, at 12:31 PM, Doug Adams wrote: > Joe (et all), > > Well stated, let me summarize my take away. > > 1. If I match the name in the firmware file name (e.g. "Hermes", "Metis", "Angelia") with the Board ID from my Radio (translated to the appropriate string) I will never load a non-operative firmware (it may have minor issues such as the filter control but it will work). > > 2. We should suggest to those who create firmware files that they only use numbered versions (i.e. no suffixes). > > I can live with #1, I'll implement it in my code as a Warning (to keep me from doing something dumb, I don't own a Blaster, yet). I'm not sure how we get people to comply with #2. > > > On Aug 11, 2014, at 2:15 PM, Joe Martin K5SO wrote: > >> Doug, >> >> RR, understood; but I don?t entirely agree with your assessment of the present situation. Let me respond to each of the issues to which I refer: >> >> .... > >> These are complex, high-performance radios and they need marginally compentent users at least in order to be able to realize the advantages that they can offer. Again, my opion. You?re all welcome to have a different opinion, if you wish. >> >> 73, Joe K5SO >> >> > > 73?s > Doug - K3TZR > > > > > > 1407782819.0 From douglas.adams at me.com Mon Aug 11 11:48:50 2014 From: douglas.adams at me.com (Doug Adams) Date: Mon, 11 Aug 2014 14:48:50 -0400 Subject: [hpsdr] Radio (Board) Identification In-Reply-To: References: <10E4B834-1BA9-4312-9ABD-E8F4B45132A8@me.com> <00F07606-EA0A-480C-BD1B-C6DD143BCEFD@valornet.com> Message-ID: <1B7A282F-FFC2-4C41-B1BC-B5347FF2DD1A@me.com> Thanks Dave, Although I haven't done any C++ in years I looked through the code and got the idea. I see that you are doing what I've decided to do (see my last post), making sure the firmware file name jives with the Board ID. I also found the definitions for the Max Timeouts for each board which I'll incorporate into my programmer. Hopefully I won't brick my radio in the process of debugging my code. On Aug 11, 2014, at 2:22 PM, Dave Larsen wrote: > Doug -- > > in the HPSDRProgrammer the code you are looking for is in http://svn.tapr.org/repos_sdr_hpsdr/trunk/KV0S/hpsdr-programmers/HPSDRProgrammerV2-nopcap/mainwindow.cpp in the browse function. > > The current HPSDRProgrammer talks to the old firmware to load the flash memory. You are right that the a and b are not kept. Joe and Phil produce most of the firmware for these boards and the naming is up to them. Internally the store the board type and the firmware version is all that is stored and read. > > Part of the issue is some of this changes the bootloader firm, which is install at manufacture not not changed. This is the recover system. we have no causal system for users to replace the bootloader. > > Hope this helps > > Dave KV0S > 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vbv at blueyonder.co.uk Mon Aug 11 13:54:18 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 11 Aug 2014 21:54:18 +0100 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> <53E8EA3D.9060807@blueyonder.co.uk> Message-ID: <53E92D7A.3090004@blueyonder.co.uk> Hi Steve and Kevin, This time instead of the KV0S svn I used "svn co http://svn.tapr.org/repos_sdr_hpsdr/trunk/N6LYT/Qt" which built without changes slipstream:/usr/src/Qt/trunk # ls -l bin total 2484 -rwxr-xr-x 1 root root 1481425 Aug 11 20:33 QtDSPServer -rwxr-xr-x 1 root root??? 396047 Aug 11 20:32 QtHPSDRServer -rwxr-xr-x 1 root root??? 663150 Aug 11 20:34 QtRadio Building on openSUSE which uses lib64 instead of lib. libusb-1.0 is in /usr/include. Makefile changes ========== ghpsdr ---------- INCLUDES=-I. -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/gdk-pixbuf-2.0\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/atk-1.0 -I/usr/include/cairo\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/pango-1.0 -I/usr/include/glib-2.0\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1\ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/freetype2 -I/usr/include/libpng12 \ ??? ??? ??? ??? ??? ??? ??? ??? -I/usr/include/libusb-1.0 Exploded and built DttSP.tar.gz in the ghpsdr directory LIBS=-L. -L/usr/src/openHPSDR/ghpsdr/DttSP -lDttSP -lpthread -lusb-1.0\ ??? ??? ??? ??? -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0\ ??? ??? ??? ??? -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lz\ ??? ??? ??? ??? -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lfftw3f slipstream:/usr/src/openHPSDR/ghpsdr # ls -l bin total 1336 -rwxr-xr-x 1 root root 1126746 Aug 11 20:47 ghpsdr -rwxr-xr-x 1 root root??? ??? ??? ??? 256 Aug 11 20:40 ghpsdr.sh -rw-r--r-- 1 root root??? ??? 21032 Aug 11 20:40 icon.png -rwxr-xr-x 1 root root??? ??? ??? 1343 Aug 11 20:40 initozy drwxr-xr-x 2 root root??? ??? ??? 4096 Aug 11 20:40 linux64 -rwxr-xr-x 1 root root??? ??? 14555 Aug 11 20:40 loadFPGA -rwxr-xr-x 1 root root??? ??? 14324 Aug 11 20:40 loadFW drwxr-xr-x 2 root root??? ??? ??? 4096 Aug 11 20:40 mac -rw-r--r-- 1 root root??? ??? 21862 Aug 11 20:40 ozyfw-sdr1k.hex -rw-r--r-- 1 root root??? 121875 Aug 11 20:40 Ozy_Janus.rbf -rwxr-xr-x 1 root root??? ??? 14687 Aug 11 20:40 write_i2c ghpsdr3-alex always has been OK. 73 ... Sid. -- 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 1407790458.0 From andrea.montefusco at gmail.com Mon Aug 11 14:04:08 2014 From: andrea.montefusco at gmail.com (andrea montefusco) Date: Mon, 11 Aug 2014 23:04:08 +0200 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: <1407708969.5462.23.camel@Barossa> References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> <1407708969.5462.23.camel@Barossa> Message-ID: On Aug 11, 2014 12:16 AM, "Berndt Josef Wulf" wrote: > > G'day, > > A modified version of cuSDR can be downloaded from > >http://www.ping.net.au/20140126_cuSDR64src.tar.gz > > It requires QT5 and may not work with the current firmware change, so > your mileage may wary. Hi Berndt, That is a good news, especially for people trying to use cuSDR on Jetson board: together with Ken N9VV we compiled the original cuSDR but we didn't manage to achieve a proper working with the Qt 4.x. In any case, I just compiled your code with qt 5.3 on Ubuntu 12.04 (i5) and it works well (Metis 2.8, Mercury 3.4). *am* -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vbv at blueyonder.co.uk Mon Aug 11 17:29:04 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Tue, 12 Aug 2014 01:29:04 +0100 Subject: [hpsdr] mercury deaf [was Hello] In-Reply-To: References: <6BAB98F8-3D9E-46CD-8E9A-DE004F1927F5@ad0es.net> <53E8EA3D.9060807@blueyonder.co.uk> Message-ID: <53E95FD0.4000106@blueyonder.co.uk> Hi Steve and Kevin, Instead of the KV0S svn I use "svn co http://svn.tapr.org/repos_sdr_hpsdr/trunk/N6LYT/Qt" built without changes /usr/src/Qt/trunk # ls -l bin total 2484 -rwxr-xr-x 1 root root 1481425 Aug 11 20:33 QtDSPServer -rwxr-xr-x 1 root root?????? 396047 Aug 11 20:32 QtHPSDRServer -rwxr-xr-x 1 root root?????? 663150 Aug 11 20:34 QtRadio Building on openSUSE which uses lib64. libusb-1.0 is in /usr/include. Makefile changes ========== ghpsdr ---------- INCLUDES=-I. -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include\ -I/usr/include/gdk-pixbuf-2.0\ -I/usr/include/atk-1.0 -I/usr/include/cairo\ -I/usr/include/pango-1.0 -I/usr/include/glib-2.0\ -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1\ -I/usr/include/freetype2 -I/usr/include/libpng12 \ -I/usr/include/libusb-1.0 Built DttSP.tar.gz in ghpsdr directory LIBS=-L. -L/usr/src/openHPSDR/ghpsdr/DttSP -lDttSP -lpthread -lusb-1.0\ -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0\ -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lz\ -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lfftw3f slipstream:/usr/src/openHPSDR/ghpsdr # ls -l bin/ghpsdr -rwxr-xr-x 1 root root 1126746 Aug 11 20:47 ghpsdr ghpsdr3-alex always has been OK. 73 ... Sid. -- 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 1407803344.0 From g3vbv at blueyonder.co.uk Mon Aug 11 17:39:58 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Tue, 12 Aug 2014 01:39:58 +0100 Subject: [hpsdr] 20140126_cuSDR64src In-Reply-To: References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> <1407708969.5462.23.camel@Barossa> Message-ID: <53E9625E.5070203@blueyonder.co.uk> No problems on openSUSE x86_64, built with Qt-5.3.1. 73 ... Sid. On 11/08/14 22:04, andrea montefusco wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > > On Aug 11, 2014 12:16 AM, "Berndt Josef Wulf" > wrote: > > > > G'day, > > > > A modified version of cuSDR can be downloaded from > > > >http://www.ping.net.au/20140126_cuSDR64src.tar.gz > > > > It requires QT5 and may not work with the current firmware change, so > > your mileage may wary. > > -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vbv at blueyonder.co.uk Tue Aug 12 12:46:15 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Tue, 12 Aug 2014 20:46:15 +0100 Subject: [hpsdr] 20140126_cuSDR64src In-Reply-To: <53E9625E.5070203@blueyonder.co.uk> References: <839EBB77-D591-4CB8-A393-234BE29D1EA1@ad0es.net> <1407708969.5462.23.camel@Barossa> <53E9625E.5070203@blueyonder.co.uk> Message-ID: <53EA6F07.8060000@blueyonder.co.uk> Hi Andrea, Just for fun I built it on the ODROID-U3 but have not got around to testing it. root at odroidu3:/a1/ANDREA/cuSDR64# file bin/cuSDR64 bin/cuSDR64: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=ad66531161d9dd1be3a83e4720c1436343b867ef, not stripped root at odroidu3:/a1/ANDREA/cuSDR64# cuSDR32 modified and built with qt-5.3.1 should also be no problem. 73 ... Sid. On 12/08/14 01:39, Sid Boyce wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > No problems on openSUSE x86_64, built with Qt-5.3.1. > 73 ... Sid. > > On 11/08/14 22:04, andrea montefusco wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> >> >> >> On Aug 11, 2014 12:16 AM, "Berndt Josef Wulf" > > wrote: >> > >> > G'day, >> > >> > A modified version of cuSDR can be downloaded from >> > >> >http://www.ping.net.au/20140126_cuSDR64src.tar.gz >> > >> > It requires QT5 and may not work with the current firmware change, so >> > your mileage may wary. >> >> > > -- > 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 > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gokoyev+k3it at gmail.com Thu Aug 14 07:14:26 2014 From: gokoyev+k3it at gmail.com (k3it) Date: Thu, 14 Aug 2014 10:14:26 -0400 Subject: [hpsdr] Updates to the Skimmer server interface DLL v14.8.13 Message-ID: An updated version of HermesIntf.dll Skimmer server interface for HPSDR is available at *https://sourceforge.net/projects/hermesintf/files/ * new h/w support: - Afedri SDR-net in HPSDR emulation mode (firmware 228e and higher) - N1GP RTL_hpsdr (see https://github.com/n1gp/rtl_hpsdr ) - up to seven receivers in Hermes depending on the firmware revision. Support of the latest v2.9 firmware (4 rcvrs) - additonal HPSDR variants (Angelia, Metis, etc) increased logging level in HermesIntf_log_file.txt Supported sample rates/receivers: 48/96/192 Khz Hermes: - Firmware version *1.8* (download from the dxatlas.com web site) - 7 receivers - Firmware version 2.4,2.5 - 5 receivers - Firmware version 2.9 - 4 receivers - Other fw revisions: defaults to 4 receivers Angelia: - 7 receivers Metis: - 4 receivers N1GP RTL dongle in HPSDR emulation mode: - up to 8 receivers, depending on the number of connected dongles Afedri SDR-NET single and dual channel in HPSDR emulation mode: - 1 or 2 receivers Please email if you run into any problems 73! Vasiliy K3IT -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrospopo at sbcglobal.net Mon Aug 11 09:38:50 2014 From: jrospopo at sbcglobal.net (Jim Rospopo) Date: Mon, 11 Aug 2014 11:38:50 -0500 Subject: [hpsdr] Newbie Question on computer and Munin Message-ID: <023201cfb582$bb967750$32c365f0$@sbcglobal.net> Newbie question, I just got the rest of the cards for my HPSDR. I was wondering what are the minimum requirements for the computer. I'll most likely be using the PowerSDR software or I may use it on my iMac with those programs. Are these programs optimized for the intel processors or will the AMD processors work equally well ? Also any minimum RAM requirements and or processor speeds ? Also, is there any more information on the Munin PA ? I know there was a group buy a while back. Are any kits still available from that buy. I also heard that TAPR was thinking of offering it as a kit. Is there any more information on that front. I'm sure as I proceed I'll have more questions. Excited to get this put together and operating. 73's Jim KE4CON -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa8k73 at gmail.com Fri Aug 15 19:23:24 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 15 Aug 2014 22:23:24 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/16 Message-ID: <53EEC09C.2040106@gmail.com> The 16/Aug TeamSpeak mp3 (61 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3511 > or < http://www.hamsdr.com/dnld.aspx > Only silence truncation editing was done on this recording. 1408155804.0 From phil at pharman.org Sun Aug 17 01:36:07 2014 From: phil at pharman.org (Phil Harman) Date: Sun, 17 Aug 2014 16:36:07 +0800 Subject: [hpsdr] Hermes manual update Message-ID: <33210BB5CEBB48C2BA7FC92CBE75EE0F@ShackPC2> All, There is an update to the Hermes User Manual (V1.18) available from: http://openhpsdr.org/documents.php This contains additional information on the use of J17 when an external supply is used. Thanks to Rob, VE3EW, for the updated information. 73 Phil...VK6PH --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at vspl.co.uk Sun Aug 17 09:37:01 2014 From: chris at vspl.co.uk (Chris Smith) Date: Sun, 17 Aug 2014 17:37:01 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 Message-ID: <20140817163704.A6AAD48278@diego.dreamhost.com> Hi Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. Eventually cuSDR64 built and I could run it on the TK1 It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? Exciting to be able to use my TK1 in anger. Cheers & 73 Chris G4NUX 1408293421.0 From wulf at ping.net.au Sun Aug 17 14:02:25 2014 From: wulf at ping.net.au (Berndt Josef Wulf) Date: Mon, 18 Aug 2014 06:32:25 +0930 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <20140817163704.A6AAD48278@diego.dreamhost.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <1408309345.3501.6.camel@Barossa> G'day Chris, The -j4 option defines the number of threads being used for the build process in this case 4. I use -j n where n is number of CPU cores available on the system +1. It significantly speeds up the building process on multi-core systems. cuSDR's CPU load is generally high including Intel based *nix systems. I never looked into this, as I still hoping for an updated version from Hermann. The chief reasons for me using cuSDR is that it runs under Linux/NetBSD and the many features that made using it a pleasure. 73, Berndt VK5ABN On Sun, 2014-08-17 at 17:37 +0100, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my > recently acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for > some years now, building the libraries from sources under Fedora Linux > & OSX. I found the published build instructions using git a bit > longwinded but eventually succeeded. Does anyone know what the -j4 > option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after > changing the symlink in /usr/bin so that qmake pointed to the Qt-5 > version in /usr/local/Qt-5/bin I could run qmake at the top level of > cuSDR to bring the Makefile up to date. I didn't do a make clean so > some .o files reported "wrong file type" but removing the 3 offending > .o files led me to the next problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 > https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz > ) and apart from configure requiring a couple of qualifiers ( > ./configure --enable-single --enable-shared ) that library built and > installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run > cuSDR on any platform before) but everything appeared to be working. My > Atlas hardware was correctly reported along with ancient f/w versions > and I could hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a > roller wheel in the shack so the only way I seem to be able to tune is > to drag the frequency bar under the display left-right. That is far too > crude to tune an individual QSO but got me some audio recognisable as a > contact. > > One thing which alarms me slightly is that the CPU usage reported is in > the range 152-175% I assume that is reporting that more than one core > (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web > page: http://openhpsdr.org Archives: > http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408309345.0 From g3vbv at blueyonder.co.uk Sun Aug 17 15:12:17 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Sun, 17 Aug 2014 23:12:17 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <20140817163704.A6AAD48278@diego.dreamhost.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <53F128C1.7040900@blueyonder.co.uk> Hi Chris, As mentioned - The first impression is that the TK1 is 64-bit, but it is quad-core 32-bit. It's still a powerful beast, CUDA ensures that. The next version apparently due later this year is dual-core 64-bit. 20140126_cuSDR64src.tar.gz comes with .o files in bld/o which are compiled x86_64 files, "make clean" will get rid of them, then do "make -j 4". Be aware that different distros, Fedora, openSUSE, Ubuntu etc. use different package names so you must refine your search terms. Typically all distros provide most stuff so no need to build core applications, libraries or utilities. Unless you need a library at a higher level than the distro provides, avoid building and installing what is already provided. You can create deep pits to fall into later, sometimes much later if you are not careful. Ubuntu -- apt-cache search fftw. Fedora -- yum search fftw. openSUSE -- zypper se fftw Don't be tempted to enter package names as they may appear in another distro. When in doubt shorten the search string, e.g There are no packages with fftw3 in the name in Fedora while there are many in openSUSE and Ubuntu but again the package names differ. # yum search fftw3 Loaded plugins: langpacks, refresh-packagekit Warning: No matches found for: fftw3 No matches found These are the fft libraries installed in Fedora 20. # rpm -qa|grep fft fftw-libs-quad-3.3.4-3.fc20.x86_64 fftw-libs-single-3.3.4-3.fc20.x86_64 fftw-3.3.4-3.fc20.x86_64 fftw-libs-3.3.4-3.fc20.x86_64 fftw-libs-double-3.3.4-3.fc20.x86_64 fftw-devel-3.3.4-3.fc20.x86_64 fftw-libs-long-3.3.4-3.fc20.x86_64 Building Qt5, recommend using the instructions for ghpsdr3-alex which work on any platform. The instructions on the wiki for building ghpsdr3-alex avoid the use of symlinks, e.g if qt5 is built in /home/fred - "export PATH=/home/fred/qt5/qtbase/bin:$PATH" sets it up to use qt5. # qmake -v QMake version 3.0 Using Qt version 5.3.1 in /home/fred/qt5/qtbase/lib 73 ... Sid. On 17/08/14 17:37, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. > > One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- 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 1408313537.0 From chris at vspl.co.uk Sun Aug 17 20:47:21 2014 From: chris at vspl.co.uk (Chris Smith) Date: Mon, 18 Aug 2014 04:47:21 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <53F128C1.7040900@blueyonder.co.uk> References: <20140817163704.A6AAD48278@diego.dreamhost.com> <53F128C1.7040900@blueyonder.co.uk> Message-ID: <20140818035052.63DBD48319@diego.dreamhost.com> Hi Sid As I mentioned off list I'm not a fan of Debian based distros because I find apt so difficult to use compared to yum. But by widening my search pattern in apt-cache search I was able to find libfftw3, so I've removed the version I built from sources and installed the package. cuSDR builds OK so I'm happy with that. Regarding Qt5, I would normally add to PATH but wanted a quick and dirty fix so changing the symlink was favourite. :-) 73, Chris G4NUX Sent from my iPad > On 17 Aug 2014, at 23:12, Sid Boyce wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Chris, > As mentioned - The first impression is that the TK1 is 64-bit, but it is quad-core 32-bit. It's still a powerful beast, CUDA ensures that. > > The next version apparently due later this year is dual-core 64-bit. > > 20140126_cuSDR64src.tar.gz comes with .o files in bld/o which are compiled x86_64 files, "make clean" will get rid of them, then do "make -j 4". > > Be aware that different distros, Fedora, openSUSE, Ubuntu etc. use different package names so you must refine your search terms. > Typically all distros provide most stuff so no need to build core applications, libraries or utilities. > Unless you need a library at a higher level than the distro provides, avoid building and installing what is already provided. You can create deep pits to fall into later, sometimes much later if you are not careful. > > Ubuntu -- apt-cache search fftw. > Fedora -- yum search fftw. > openSUSE -- zypper se fftw > > Don't be tempted to enter package names as they may appear in another distro. When in doubt shorten the search string, e.g There are no packages with fftw3 in the name in Fedora while there are many in openSUSE and Ubuntu but again the package names differ. > # yum search fftw3 > Loaded plugins: langpacks, refresh-packagekit > Warning: No matches found for: fftw3 > No matches found > > These are the fft libraries installed in Fedora 20. > # rpm -qa|grep fft > fftw-libs-quad-3.3.4-3.fc20.x86_64 > fftw-libs-single-3.3.4-3.fc20.x86_64 > fftw-3.3.4-3.fc20.x86_64 > fftw-libs-3.3.4-3.fc20.x86_64 > fftw-libs-double-3.3.4-3.fc20.x86_64 > fftw-devel-3.3.4-3.fc20.x86_64 > fftw-libs-long-3.3.4-3.fc20.x86_64 > > Building Qt5, recommend using the instructions for ghpsdr3-alex which work on any platform. > The instructions on the wiki for building ghpsdr3-alex avoid the use of symlinks, e.g if qt5 is built in /home/fred - "export PATH=/home/fred/qt5/qtbase/bin:$PATH" sets it up to use qt5. > # qmake -v > QMake version 3.0 > Using Qt version 5.3.1 in /home/fred/qt5/qtbase/lib > 73 ... Sid. > >> On 17/08/14 17:37, Chris Smith wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi >> >> Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. >> >> Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? >> >> Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. >> >> I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. >> >> Eventually cuSDR64 built and I could run it on the TK1 >> >> It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. >> >> The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. >> >> One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? >> >> Exciting to be able to use my TK1 in anger. >> >> Cheers & 73 >> >> Chris G4NUX >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > -- > 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 > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408333641.0 From g3vbv at blueyonder.co.uk Mon Aug 18 03:30:39 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 18 Aug 2014 11:30:39 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <53f1781b.ef21700a.2a89.ffff8ac3SMTPIN_ADDED_MISSING@mx.google.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> <53F128C1.7040900@blueyonder.co.uk> <53f1781b.ef21700a.2a89.ffff8ac3SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <53F1D5CF.4010805@blueyonder.co.uk> Hi Chris, I use whatever is before me, I have had to do that for decades working with 12 or more different OS's - yum search, zypper search/se, apt-*, aptitude search, pacman -S, not much of a difference between them really. I also stash tons of executable scripts that lighten the key pounding load. I have them in /usr/local/mybin which is permanently added to PATH. lancelot at slipstream:~> cat /usr/local/mybin/BUILD_GNURADIO #!/bin/sh cmake -DPYTHON_EXECUTABLE=/usr/bin/python2.7 -DPYTHON_INCLUDE_DIR=/usr/include/python2.7 -DPYTHON_LIBRARY=/usr/lib64/libpython2.7.so -DCMAKE_INSTALL_PREFIX=/usr . lancelot at slipstream:~> cat /usr/local/mybin/QUARTUS #!/bin/sh cd /home/lancelot/altera/13.0/quartus/bin/ ./quartus& lancelot at slipstream:~> cat /usr/local/mybin/HERMES_384K #!/bin/sh hpsdr-server --hermes 255 --samplerate 384000 --interface enp3s0 & There is only one OS I have ever shied away from as I was never required to use it to earn a daily crust. The one with the fur coat and no under garments. 73 ... Sid. On 18/08/14 04:47, Chris Smith wrote: > Hi Sid > > As I mentioned off list I'm not a fan of Debian based distros because I find apt so difficult to use compared to yum. But by widening my search pattern in apt-cache search I was able to find libfftw3, so I've removed the version I built from sources and installed the package. cuSDR builds OK so I'm happy with that. > > Regarding Qt5, I would normally add to PATH but wanted a quick and dirty fix so changing the symlink was favourite. :-) > > 73, Chris G4NUX > > Sent from my iPad > >> On 17 Aug 2014, at 23:12, Sid Boyce wrote: >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Chris, >> As mentioned - The first impression is that the TK1 is 64-bit, but it is quad-core 32-bit. It's still a powerful beast, CUDA ensures that. >> >> The next version apparently due later this year is dual-core 64-bit. >> >> 20140126_cuSDR64src.tar.gz comes with .o files in bld/o which are compiled x86_64 files, "make clean" will get rid of them, then do "make -j 4". >> >> Be aware that different distros, Fedora, openSUSE, Ubuntu etc. use different package names so you must refine your search terms. >> Typically all distros provide most stuff so no need to build core applications, libraries or utilities. >> Unless you need a library at a higher level than the distro provides, avoid building and installing what is already provided. You can create deep pits to fall into later, sometimes much later if you are not careful. >> >> Ubuntu -- apt-cache search fftw. >> Fedora -- yum search fftw. >> openSUSE -- zypper se fftw >> >> Don't be tempted to enter package names as they may appear in another distro. When in doubt shorten the search string, e.g There are no packages with fftw3 in the name in Fedora while there are many in openSUSE and Ubuntu but again the package names differ. >> # yum search fftw3 >> Loaded plugins: langpacks, refresh-packagekit >> Warning: No matches found for: fftw3 >> No matches found >> >> These are the fft libraries installed in Fedora 20. >> # rpm -qa|grep fft >> fftw-libs-quad-3.3.4-3.fc20.x86_64 >> fftw-libs-single-3.3.4-3.fc20.x86_64 >> fftw-3.3.4-3.fc20.x86_64 >> fftw-libs-3.3.4-3.fc20.x86_64 >> fftw-libs-double-3.3.4-3.fc20.x86_64 >> fftw-devel-3.3.4-3.fc20.x86_64 >> fftw-libs-long-3.3.4-3.fc20.x86_64 >> >> Building Qt5, recommend using the instructions for ghpsdr3-alex which work on any platform. >> The instructions on the wiki for building ghpsdr3-alex avoid the use of symlinks, e.g if qt5 is built in /home/fred - "export PATH=/home/fred/qt5/qtbase/bin:$PATH" sets it up to use qt5. >> # qmake -v >> QMake version 3.0 >> Using Qt version 5.3.1 in /home/fred/qt5/qtbase/lib >> 73 ... Sid. >> >>> On 17/08/14 17:37, Chris Smith wrote: >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> Hi >>> >>> Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. >>> >>> Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? >>> >>> Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. >>> >>> I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. >>> >>> Eventually cuSDR64 built and I could run it on the TK1 >>> >>> It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. >>> >>> The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. >>> >>> One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? >>> >>> Exciting to be able to use my TK1 in anger. >>> >>> Cheers & 73 >>> >>> Chris G4NUX >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> -- >> 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 >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 1408357839.0 From hvh.net at gmail.com Mon Aug 18 04:24:23 2014 From: hvh.net at gmail.com (Hermann) Date: Mon, 18 Aug 2014 13:24:23 +0200 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <20140817163704.A6AAD48278@diego.dreamhost.com> References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: Dear Chris, congratulations! What I noticed last year when I did some experiments with cuSDR on my Gentoo box is also a higher CPU load compared to a Windows box. I did not took a closer look at yet where this might come from, but it could depend on many things. I will compile cuSDR on my Jetson in short (I hope so, hi) and will take a closer look at. Maybe the strategy of advising/generating threads in cuSDR has to be modified to suit the Linux scheduler, but this is purely speculative for now. 73, Hermann DL3HVH On Sun, Aug 17, 2014 at 6:37 PM, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my recently > acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for some > years now, building the libraries from sources under Fedora Linux & OSX. I > found the published build instructions using git a bit longwinded but > eventually succeeded. Does anyone know what the -j4 option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after > changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version > in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring > the Makefile up to date. I didn't do a make clean so some .o files reported > "wrong file type" but removing the 3 offending .o files led me to the next > problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 > https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz > ) and apart from configure requiring a couple of qualifiers ( ./configure > --enable-single --enable-shared ) that library built and installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run cuSDR > on any platform before) but everything appeared to be working. My Atlas > hardware was correctly reported along with ancient f/w versions and I could > hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a > roller wheel in the shack so the only way I seem to be able to tune is to > drag the frequency bar under the display left-right. That is far too crude > to tune an individual QSO but got me some audio recognisable as a contact. > > One thing which alarms me slightly is that the CPU usage reported is in > the range 152-175% I assume that is reporting that more than one core > (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at vspl.co.uk Mon Aug 18 06:32:16 2014 From: chris at vspl.co.uk (Chris Smith) Date: Mon, 18 Aug 2014 14:32:16 +0100 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <20140818133219.75557481E0@diego.dreamhost.com> Hi Herman I'm so encouraged by the success of this venture that I'm going to build cuSDR64 on my HPSDR dual-boot system - WinXP/F19. I'd like to be shot of Windows for good. PowerSDR is the only piece of software that I currently use that needs Windows. I'll let you know how I get on there. 73, Chris G4NUX On 18 Aug 2014, at 12:24, Hermann wrote: > Dear Chris, > > congratulations! What I noticed last year when I did some experiments with cuSDR on my Gentoo box is also a higher CPU load compared to a Windows box. I did not took a closer look at yet where this might come from, but it could depend on many things. I will compile cuSDR on my Jetson in short (I hope so, hi) and will take a closer look at. Maybe the strategy of advising/generating threads in cuSDR has to be modified to suit the Linux scheduler, but this is purely speculative for now. > > > 73, Hermann DL3HVH > > > On Sun, Aug 17, 2014 at 6:37 PM, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > Just thought I'd report progress I've made building cuSDR64 on my recently acquired Jetson TK1. > > Building Qt-5 was reasonably straightforward. I've been using Qt for some years now, building the libraries from sources under Fedora Linux & OSX. I found the published build instructions using git a bit longwinded but eventually succeeded. Does anyone know what the -j4 option on make does? > > Download of the cuSDR source was easy, thanks to Brandt, and, after changing the symlink in /usr/bin so that qmake pointed to the Qt-5 version in /usr/local/Qt-5/bin I could run qmake at the top level of cuSDR to bring the Makefile up to date. I didn't do a make clean so some .o files reported "wrong file type" but removing the 3 offending .o files led me to the next problem - no libfftw3. > > I downloaded the source for fftw3 ( wget -c -t0 https://launchpad.net/ubuntu/+archive/primary/+files/fftw3_3.3.3.orig.tar.gz ) and apart from configure requiring a couple of qualifiers ( ./configure --enable-single --enable-shared ) that library built and installed smoothly. > > Eventually cuSDR64 built and I could run it on the TK1 > > It took me a while to find my way around the display (I've not run cuSDR on any platform before) but everything appeared to be working. My Atlas hardware was correctly reported along with ancient f/w versions and I could hear audio from Mercury. > > The one problem I'm having is tuning. I don't have a USB mouse with a roller wheel in the shack so the only way I seem to be able to tune is to drag the frequency bar under the display left-right. That is far too crude to tune an individual QSO but got me some audio recognisable as a contact. > > One thing which alarms me slightly is that the CPU usage reported is in the range 152-175% I assume that is reporting that more than one core (maybe more than 2) is in use? > > Exciting to be able to use my TK1 in anger. > > Cheers & 73 > > Chris G4NUX > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1408368736.0 From irbsurfing at yahoo.co.uk Tue Aug 19 13:04:06 2014 From: irbsurfing at yahoo.co.uk (Andrew) Date: Tue, 19 Aug 2014 21:04:06 +0100 Subject: [hpsdr] Wideband waterfall display Message-ID: <1408478646.90961.YahooMailNeo@web171206.mail.ir2.yahoo.com> Hi, Just wondering if anyone knows of a piece of software that can show a 0-55MHz wideband waterfall display with Hermes etc? I know Kiss Konsole and CuSDR have a wideband pan-adapter, but not a waterfall as far as I know. Thanks, Andrew G4XZL -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvh.net at gmail.com Tue Aug 19 13:09:40 2014 From: hvh.net at gmail.com (Hermann) Date: Tue, 19 Aug 2014 22:09:40 +0200 Subject: [hpsdr] Wideband waterfall display In-Reply-To: <1408478646.90961.YahooMailNeo@web171206.mail.ir2.yahoo.com> References: <1408478646.90961.YahooMailNeo@web171206.mail.ir2.yahoo.com> Message-ID: Hi Andrew, Next version of cuSDR has a wideband waterfall display. In the beta this is already working. 73, Hermann DL3HVH Sent from my Nexus 5 On Aug 19, 2014 10:04 PM, "Andrew" wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > Hi, > Just wondering if anyone knows of a piece of software that can show a > 0-55MHz wideband waterfall display with Hermes etc? > I know Kiss Konsole and CuSDR have a wideband pan-adapter, but not a > waterfall as far as I know. > Thanks, > Andrew > G4XZL > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at pharman.org Wed Aug 20 00:31:26 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 15:31:26 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. In order to open the SDR world to those with PC software skills we are in the process of developing a new SDR architecture. This architecture digitises the entire 0 to 30MHz radio spectrum in real time and passes the 'raw' samples directly to an associated computer. This computer then calculates the FFT of the raw samples and subsequently processes the result as the user requires. This is not a totally new concept since both the cuSDR and KISS Konsole software uses raw ADC samples to provide the wideband bandscope displays. However, for this requirement the FFT only needs to be done at the bandscope update rate of a few 10's of times per second, which hardly taxes a modern PC at all. The new concept requires that we take the FFT of all samples in real-time. This has been possible in the past - if you had access to a Cray super computer! Well now we do have access to very low cost computers that provide the processing power we need. One example of this is the new Nvidia Jetson TK1 single board computer. At a cost of $192 this board contains four ARM CPUs plus 192 CUDA processors. More details of this remarkable board can be found here: https://developer.nvidia.com/jetson-tk1 Since the CUDA cores can process data in parallel, we can use these to perform the high speed FFT. John, G0ORX, has written preliminary code for the Jetson board and has confirmed that it has the necessary performance we require. The test environment consisted of a Jetson board connected via Gigabit Ethernet to an Angelia board. A special version of FPGA code was written for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the Jetson board. We used raw Ethernet frames over the Gigabit link, in order to maximise the link bandwidth, since we require a sustained 983Mbps transfer rate. Whilst it's still early days, and there is much more to be done, this critical early success does indicate that this new architecture has a very promising future. The Jetson board is taking the role of an 'SDR Server' which I have written about in the past. In which case what benefits does this new architecture provide to openHPSR? 1. The FPGA code is greatly simplified, is easier to write and maintain, and hence uses a small percentage of the space available with a subsequent reduction in power consumption. 2. The protocol between the SDR hardware and the SDR Server is greatly simplified since the SDR hardware only has to connect to a single, dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer required. The SDR Server simply needs to know the MAC address of the SDR hardware in order to communicate. It should be possible for a single SDR hardware board to feed multiple SDR Servers, but that's something for the future. 3. Virtually all the signal processing is undertaken on the associated single board computer (SBC) or (suitable) PC. If sufficient processing power is available then the GUI can run on the same SBC. Alternatively the user's normal PC (which does not require to be high performance since it does not do any significant digital signal processing) or a Tablet, cell phone etc could be used. 4. Many more users have the necessary skills and experience to support, maintain and further develop the code. New features are added to the SDR Server code rather than the FPGA code. 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA and/or power supply restrictions may have limited adding new features. 6. Future hardware upgrades will be to the associated SBC where faster and lower cost options can be expected. Nvidia have already indicated that a 64 bit board will be available in the near future. 7. Remote access to an SDR via the Internet will enable multiple users to share the SDR with each selecting their desired frequency, bandwidth and mode. There are other potential benefits relating to simpler and lower cost SDR hardware, but that is for the future. For want of a name we are calling this new architecture 'Direct Fourier Conversion' (DFC). For those that are already experimenting with the Jetson board we do intend to release the DFC FPGA code for both Angelia and Hermes boards and I will advise when, and where, this is available. John's code is presently not available, so please don't pester him, but as soon as it reaches Beta stage it will be released. Please join me in congratulating John on this exciting development. 73 Phil....VK6PH 1408519886.0 From chris at vspl.co.uk Wed Aug 20 00:42:58 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 08:42:58 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <20140820074302.6AB7048864@diego.dreamhost.com> Hi Phil I had a feeling, when I saw your paper and Hermann's at Friedrischafen, that DFC was the way things were going. Which is why I jumped on the TK1 bandwagon. Will there ever be a way of using the Mercury front end to supply the raw packets, perhaps with a bespoke daughter board? Congrats to John whom I had the pleasure of speaking to at Friedrischafen. I'm sure we all look forward to the new era of SDR in the amateur radio arena. Cheers & 73 Chris G4NUX On 20 Aug 2014, at 08:31, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408520578.0 From roland.etienne at free.fr Wed Aug 20 00:48:52 2014 From: roland.etienne at free.fr (Roland Etienne) Date: Wed, 20 Aug 2014 09:48:52 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <0EDA19C686524970B4E75CD8483127AE@F8CHKAtom> Hi Phil, Very exciting news! Congrats to John and all of you, crazy programmers! how do you find the time to do all that job ?? Thanks a lot for the fun you're giving us! 73, Roland F8CHK > -----Message d'origine----- > De?: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] De la part de Phil > Harman > Envoy??: mercredi 20 ao?t 2014 09:31 > ??: hpsdr at lists.openhpsdr.org > Objet?: [hpsdr] openHPSDR at the forefront of SDR development > > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > .... > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > .... > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr- > openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408520932.0 From phil at pharman.org Wed Aug 20 01:22:48 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 16:22:48 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: Hi Chris, The limitation of using the Mercury board together with Metis is the bandwidth of the Alex bus. If would could couple the two boards together in a suitable way then we can use the existing Mercury board. 73 Phil...VK6PH > Hi Phil > > I had a feeling, when I saw your paper and Hermann's at Friedrischafen, > that DFC was the way things were going. Which is why I jumped on the TK1 > bandwagon. > > Will there ever be a way of using the Mercury front end to supply the raw > packets, perhaps with a bespoke daughter board? > > Congrats to John whom I had the pleasure of speaking to at Friedrischafen. > I'm sure we all look forward to the new era of SDR in the amateur radio > arena. > > Cheers & 73 > > Chris G4NUX > > On 20 Aug 2014, at 08:31, Phil Harman wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> I'm delighted to be able to report that we have been able to develop, to >> proof-of-concept stage, a new SDR architecture. >> >> Current SDRs use the software equivalent of zero IF techniques, i.e. >> DDC, >> in order to provide (multiple) receivers. Whist this is quite >> effective, >> much of the initial DSP work is done using FPGAs, or a combination of >> FPGA >> plus dedicated DSP chips and microprocessors, rather than totally within >> the PC. >> >> As more complex features are added, the size and complexity of the FPGA >> and DSP code increases. The skills to write, debug and maintain this >> code >> is only available via a small percentage of software engineers, or >> enthusiasts, in comparison to those able to write code for PC based >> hardware. >> >> In order to open the SDR world to those with PC software skills we are >> in >> the process of developing a new SDR architecture. >> >> This architecture digitises the entire 0 to 30MHz radio spectrum in real >> time and passes the 'raw' samples directly to an associated computer. >> >> This computer then calculates the FFT of the raw samples and >> subsequently >> processes the result as the user requires. >> >> This is not a totally new concept since both the cuSDR and KISS Konsole >> software uses raw ADC samples to provide the wideband bandscope >> displays. >> >> However, for this requirement the FFT only needs to be done at the >> bandscope update rate of a few 10's of times per second, which hardly >> taxes a modern PC at all. >> >> The new concept requires that we take the FFT of all samples in >> real-time. >> >> This has been possible in the past - if you had access to a Cray super >> computer! >> >> Well now we do have access to very low cost computers that provide the >> processing power we need. One example of this is the new Nvidia Jetson >> TK1 single board computer. At a cost of $192 this board contains four >> ARM >> CPUs plus 192 CUDA processors. >> >> More details of this remarkable board can be found here: >> >> https://developer.nvidia.com/jetson-tk1 >> >> Since the CUDA cores can process data in parallel, we can use these to >> perform the high speed FFT. >> >> John, G0ORX, has written preliminary code for the Jetson board and has >> confirmed that it has the necessary performance we require. >> >> The test environment consisted of a Jetson board connected via Gigabit >> Ethernet to an Angelia board. A special version of FPGA code was >> written >> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >> the >> Jetson board. >> >> We used raw Ethernet frames over the Gigabit link, in order to maximise >> the link bandwidth, since we require a sustained 983Mbps transfer rate. >> >> Whilst it's still early days, and there is much more to be done, this >> critical early success does indicate that this new architecture has a >> very >> promising future. >> >> The Jetson board is taking the role of an 'SDR Server' which I have >> written about in the past. >> >> In which case what benefits does this new architecture provide to >> openHPSR? >> >> 1. The FPGA code is greatly simplified, is easier to write and maintain, >> and hence uses a small percentage of the space available with a >> subsequent >> reduction in power consumption. >> >> 2. The protocol between the SDR hardware and the SDR Server is greatly >> simplified since the SDR hardware only has to connect to a single, >> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >> required. The SDR Server simply needs to know the MAC address of the >> SDR >> hardware in order to communicate. It should be possible for a single >> SDR >> hardware board to feed multiple SDR Servers, but that's something for >> the >> future. >> >> 3. Virtually all the signal processing is undertaken on the associated >> single board computer (SBC) or (suitable) PC. If sufficient processing >> power is available then the GUI can run on the same SBC. Alternatively >> the >> user's normal PC (which does not require to be high performance since it >> does not do any significant digital signal processing) or a Tablet, cell >> phone etc could be used. >> >> 4. Many more users have the necessary skills and experience to support, >> maintain and further develop the code. New features are added to the SDR >> Server code rather than the FPGA code. >> >> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >> FPGA >> and/or power supply restrictions may have limited adding new features. >> >> 6. Future hardware upgrades will be to the associated SBC where faster >> and >> lower cost options can be expected. Nvidia have already indicated that >> a >> 64 bit board will be available in the near future. >> >> 7. Remote access to an SDR via the Internet will enable multiple users >> to >> share the SDR with each selecting their desired frequency, bandwidth and >> mode. >> >> There are other potential benefits relating to simpler and lower cost >> SDR >> hardware, but that is for the future. >> >> For want of a name we are calling this new architecture 'Direct Fourier >> Conversion' (DFC). >> >> For those that are already experimenting with the Jetson board we do >> intend to release the DFC FPGA code for both Angelia and Hermes boards >> and >> I will advise when, and where, this is available. >> >> John's code is presently not available, so please don't pester him, but >> as >> soon as it reaches Beta stage it will be released. >> >> Please join me in congratulating John on this exciting development. >> >> 73 Phil....VK6PH >> >> >> >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > 1408522968.0 From dc6ny at gmx.de Wed Aug 20 01:48:31 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Wed, 20 Aug 2014 10:48:31 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <000001cfbc53$85bf7be0$913e73a0$@de> Hi Phil, Congratulations. Maybe a stupid question: Current bottleneck is the 1 Gbit/s LAN connection that makes a decimation by factor 2 necessary or limits the frequency range to 33MHz, i.e. we lose 6m band at least as raw I/Q. Is there no (economic) way to get the LAN connection faster? 14 and 16 Bit ADC/DACs are getting faster and low-jitter sampling oscillators up to 300MHz are available, hence a lot of nice applications are imaginable, hi. 73, Helmut, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von Phil Harman Gesendet: Mittwoch, 20. August 2014 09:31 An: hpsdr at lists.openhpsdr.org Betreff: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. In order to open the SDR world to those with PC software skills we are in the process of developing a new SDR architecture. This architecture digitises the entire 0 to 30MHz radio spectrum in real time and passes the 'raw' samples directly to an associated computer. This computer then calculates the FFT of the raw samples and subsequently processes the result as the user requires. This is not a totally new concept since both the cuSDR and KISS Konsole software uses raw ADC samples to provide the wideband bandscope displays. However, for this requirement the FFT only needs to be done at the bandscope update rate of a few 10's of times per second, which hardly taxes a modern PC at all. The new concept requires that we take the FFT of all samples in real-time. This has been possible in the past - if you had access to a Cray super computer! Well now we do have access to very low cost computers that provide the processing power we need. One example of this is the new Nvidia Jetson TK1 single board computer. At a cost of $192 this board contains four ARM CPUs plus 192 CUDA processors. More details of this remarkable board can be found here: https://developer.nvidia.com/jetson-tk1 Since the CUDA cores can process data in parallel, we can use these to perform the high speed FFT. John, G0ORX, has written preliminary code for the Jetson board and has confirmed that it has the necessary performance we require. The test environment consisted of a Jetson board connected via Gigabit Ethernet to an Angelia board. A special version of FPGA code was written for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the Jetson board. We used raw Ethernet frames over the Gigabit link, in order to maximise the link bandwidth, since we require a sustained 983Mbps transfer rate. Whilst it's still early days, and there is much more to be done, this critical early success does indicate that this new architecture has a very promising future. The Jetson board is taking the role of an 'SDR Server' which I have written about in the past. In which case what benefits does this new architecture provide to openHPSR? 1. The FPGA code is greatly simplified, is easier to write and maintain, and hence uses a small percentage of the space available with a subsequent reduction in power consumption. 2. The protocol between the SDR hardware and the SDR Server is greatly simplified since the SDR hardware only has to connect to a single, dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer required. The SDR Server simply needs to know the MAC address of the SDR hardware in order to communicate. It should be possible for a single SDR hardware board to feed multiple SDR Servers, but that's something for the future. 3. Virtually all the signal processing is undertaken on the associated single board computer (SBC) or (suitable) PC. If sufficient processing power is available then the GUI can run on the same SBC. Alternatively the user's normal PC (which does not require to be high performance since it does not do any significant digital signal processing) or a Tablet, cell phone etc could be used. 4. Many more users have the necessary skills and experience to support, maintain and further develop the code. New features are added to the SDR Server code rather than the FPGA code. 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA and/or power supply restrictions may have limited adding new features. 6. Future hardware upgrades will be to the associated SBC where faster and lower cost options can be expected. Nvidia have already indicated that a 64 bit board will be available in the near future. 7. Remote access to an SDR via the Internet will enable multiple users to share the SDR with each selecting their desired frequency, bandwidth and mode. There are other potential benefits relating to simpler and lower cost SDR hardware, but that is for the future. For want of a name we are calling this new architecture 'Direct Fourier Conversion' (DFC). For those that are already experimenting with the Jetson board we do intend to release the DFC FPGA code for both Angelia and Hermes boards and I will advise when, and where, this is available. John's code is presently not available, so please don't pester him, but as soon as it reaches Beta stage it will be released. Please join me in congratulating John on this exciting development. 73 Phil....VK6PH _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408524511.0 From chris at vspl.co.uk Wed Aug 20 01:48:56 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 09:48:56 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <20140820084900.495FC4861E@diego.dreamhost.com> Hi Phil I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) Cheers Chris On 20 Aug 2014, at 09:22, "Phil Harman" wrote: > Hi Chris, > > The limitation of using the Mercury board together with Metis is the > bandwidth of the Alex bus. > > If would could couple the two boards together in a suitable way then we > can use the existing Mercury board. > > 73 Phil...VK6PH > > >> Hi Phil >> >> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >> that DFC was the way things were going. Which is why I jumped on the TK1 >> bandwagon. >> >> Will there ever be a way of using the Mercury front end to supply the raw >> packets, perhaps with a bespoke daughter board? >> >> Congrats to John whom I had the pleasure of speaking to at Friedrischafen. >> I'm sure we all look forward to the new era of SDR in the amateur radio >> arena. >> >> Cheers & 73 >> >> Chris G4NUX >> >> On 20 Aug 2014, at 08:31, Phil Harman wrote: >> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> All, >>> >>> I'm delighted to be able to report that we have been able to develop, to >>> proof-of-concept stage, a new SDR architecture. >>> >>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>> DDC, >>> in order to provide (multiple) receivers. Whist this is quite >>> effective, >>> much of the initial DSP work is done using FPGAs, or a combination of >>> FPGA >>> plus dedicated DSP chips and microprocessors, rather than totally within >>> the PC. >>> >>> As more complex features are added, the size and complexity of the FPGA >>> and DSP code increases. The skills to write, debug and maintain this >>> code >>> is only available via a small percentage of software engineers, or >>> enthusiasts, in comparison to those able to write code for PC based >>> hardware. >>> >>> In order to open the SDR world to those with PC software skills we are >>> in >>> the process of developing a new SDR architecture. >>> >>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>> time and passes the 'raw' samples directly to an associated computer. >>> >>> This computer then calculates the FFT of the raw samples and >>> subsequently >>> processes the result as the user requires. >>> >>> This is not a totally new concept since both the cuSDR and KISS Konsole >>> software uses raw ADC samples to provide the wideband bandscope >>> displays. >>> >>> However, for this requirement the FFT only needs to be done at the >>> bandscope update rate of a few 10's of times per second, which hardly >>> taxes a modern PC at all. >>> >>> The new concept requires that we take the FFT of all samples in >>> real-time. >>> >>> This has been possible in the past - if you had access to a Cray super >>> computer! >>> >>> Well now we do have access to very low cost computers that provide the >>> processing power we need. One example of this is the new Nvidia Jetson >>> TK1 single board computer. At a cost of $192 this board contains four >>> ARM >>> CPUs plus 192 CUDA processors. >>> >>> More details of this remarkable board can be found here: >>> >>> https://developer.nvidia.com/jetson-tk1 >>> >>> Since the CUDA cores can process data in parallel, we can use these to >>> perform the high speed FFT. >>> >>> John, G0ORX, has written preliminary code for the Jetson board and has >>> confirmed that it has the necessary performance we require. >>> >>> The test environment consisted of a Jetson board connected via Gigabit >>> Ethernet to an Angelia board. A special version of FPGA code was >>> written >>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>> the >>> Jetson board. >>> >>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>> >>> Whilst it's still early days, and there is much more to be done, this >>> critical early success does indicate that this new architecture has a >>> very >>> promising future. >>> >>> The Jetson board is taking the role of an 'SDR Server' which I have >>> written about in the past. >>> >>> In which case what benefits does this new architecture provide to >>> openHPSR? >>> >>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>> and hence uses a small percentage of the space available with a >>> subsequent >>> reduction in power consumption. >>> >>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>> simplified since the SDR hardware only has to connect to a single, >>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>> required. The SDR Server simply needs to know the MAC address of the >>> SDR >>> hardware in order to communicate. It should be possible for a single >>> SDR >>> hardware board to feed multiple SDR Servers, but that's something for >>> the >>> future. >>> >>> 3. Virtually all the signal processing is undertaken on the associated >>> single board computer (SBC) or (suitable) PC. If sufficient processing >>> power is available then the GUI can run on the same SBC. Alternatively >>> the >>> user's normal PC (which does not require to be high performance since it >>> does not do any significant digital signal processing) or a Tablet, cell >>> phone etc could be used. >>> >>> 4. Many more users have the necessary skills and experience to support, >>> maintain and further develop the code. New features are added to the SDR >>> Server code rather than the FPGA code. >>> >>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>> FPGA >>> and/or power supply restrictions may have limited adding new features. >>> >>> 6. Future hardware upgrades will be to the associated SBC where faster >>> and >>> lower cost options can be expected. Nvidia have already indicated that >>> a >>> 64 bit board will be available in the near future. >>> >>> 7. Remote access to an SDR via the Internet will enable multiple users >>> to >>> share the SDR with each selecting their desired frequency, bandwidth and >>> mode. >>> >>> There are other potential benefits relating to simpler and lower cost >>> SDR >>> hardware, but that is for the future. >>> >>> For want of a name we are calling this new architecture 'Direct Fourier >>> Conversion' (DFC). >>> >>> For those that are already experimenting with the Jetson board we do >>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>> and >>> I will advise when, and where, this is available. >>> >>> John's code is presently not available, so please don't pester him, but >>> as >>> soon as it reaches Beta stage it will be released. >>> >>> Please join me in congratulating John on this exciting development. >>> >>> 73 Phil....VK6PH >>> >>> >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: >>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> >> > 1408524536.0 From meijer.ha at home.nl Wed Aug 20 01:58:26 2014 From: meijer.ha at home.nl (H.A.Meijer) Date: Wed, 20 Aug 2014 10:58:26 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F46332.9040601@home.nl> Phil Harman schreef op 20-8-2014 om 9:31: > ***** High Performance Software Defined Radio Discussion List ***** > > > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > Hi, I'm just a "end-user" and not a software engineer, so it's not very easy, for me, to understand all of this. Does it mean that that this "new board" is connected between your sdr transceiver (hermes etc) and your PC?. I would rater like a 'stand-alone' and 'High Performance' solution for better DSP functionality etc, and to get rid of my pc, then an extra board that just needs more soft- and firmware.... But I understand that this is very exiting for software engineers, so good luck. Bert PA2XHF --- Dit e-mailbericht bevat geen virussen en malware omdat avast! Antivirus-bescherming actief is. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dc6ny at gmx.de Wed Aug 20 02:09:52 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Wed, 20 Aug 2014 11:09:52 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F46332.9040601@home.nl> References: <53F46332.9040601@home.nl> Message-ID: <000c01cfbc56$808c9560$81a5c020$@de> Hi Bert, please see Phil's presentation 'Further prospective of HPSDR' at http://openhpsdr.org/publications.php and you will collect a lot of important info. 73, Helmut, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von H.A.Meijer Gesendet: Mittwoch, 20. August 2014 10:58 An: hpsdr at lists.openhpsdr.org Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** 1408525792.0 From ksyverud at broadpark.no Wed Aug 20 02:51:45 2014 From: ksyverud at broadpark.no (Kjell Syverud) Date: Wed, 20 Aug 2014 11:51:45 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F46FB1.2050304@broadpark.no> Hi Phil. Nice to hear you can confirm the "DFC" as you presented it in Friedrichshafen. One question, may be you commented it in Friedrichshafen, but i can not remember: Will it be possible to cover 30 to 60 MHz ? 73 LA9CY/Kjell 1408528305.0 From phil at pharman.org Wed Aug 20 04:15:36 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 19:15:36 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F46332.9040601@home.nl> References: <53F46332.9040601@home.nl> Message-ID: <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> Hi Bert, Yes, as we are today the ?new board? is connected between your SDR hardware and your PC. It may be possible to run both the SDR server and Client GUI software on the one SBC or PC. Its a little early yet to know if the Jetson board is capable of doing this. If so, then with your SDR hardware you would have a dedicated SDR that does not require an additional PC. This could all be packaged into a case with a suitable touch screen etc. You can always do that today by using a suitable SBC that will run Windows. 73 Phil...VK6PH Hi, I'm just a "end-user" and not a software engineer, so it's not very easy, for me, to understand all of this. Does it mean that that this "new board" is connected between your sdr transceiver (hermes etc) and your PC?. I would rater like a 'stand-alone' and 'High Performance' solution for better DSP functionality etc, and to get rid of my pc, then an extra board that just needs more soft- and firmware.... But I understand that this is very exiting for software engineers, so good luck. Bert PA2XHF -------------------------------------------------------------------------------- Dit e-mailbericht bevat geen virussen en malware omdat avast! Antivirus actief is. -------------------------------------------------------------------------------- _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at pharman.org Wed Aug 20 04:28:08 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 19:28:08 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F46FB1.2050304@broadpark.no> References: <53F46FB1.2050304@broadpark.no> Message-ID: <0EB6587E8CAE411C8E61A6B0215E7070@ShackPC2> Hi Kjell, Initially its not going to be possible to cover 0 to 55MHz of spectrum since with 16 bits of ADC data that would exceed the capacity of the Gigabit channel. We could reduce the ADC data to 8 bits but that would hardly meet the 'High Performance' requirement! We can still use 6m since this will alias into the 0-30MHz range, but we can't do both at the same time. We still have 16Mbps 'spare' in the Ethernet bandwidth so we may be able to include 6m using a conventional DDC. Still early days, we can use the mini PCIe interface on the Jetson board to interface to the ADC/DAC in order to run at faster sampling rates. At the moment we don't know how much spare processing capacity we have on board so still lots more tests to run. 73 Phil...VK6PH -----Original Message----- From: Kjell Syverud Sent: Wednesday, August 20, 2014 5:51 PM To: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Hi Phil. Nice to hear you can confirm the "DFC" as you presented it in Friedrichshafen. One question, may be you commented it in Friedrichshafen, but i can not remember: Will it be possible to cover 30 to 60 MHz ? 73 LA9CY/Kjell _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1408534088.0 From phil at pharman.org Wed Aug 20 04:37:31 2014 From: phil at pharman.org (Phil Harman) Date: Wed, 20 Aug 2014 19:37:31 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> Hi Chris. Alternatively, you could make a small PCB that plugged into J5 on Mercury that held the PHY, 25MHz clock and Ethernet socket. Since you no longer need any DDC code in the FPGA you would have plenty of room to house the raw Ethernet code. 'Weekend Project' anyone ? 73 Phil....VK6PH -----Original Message----- From: Chris Smith Sent: Wednesday, August 20, 2014 4:48 PM To: phil at pharman.org Cc: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development Hi Phil I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) Cheers Chris On 20 Aug 2014, at 09:22, "Phil Harman" wrote: > Hi Chris, > > The limitation of using the Mercury board together with Metis is the > bandwidth of the Alex bus. > > If would could couple the two boards together in a suitable way then we > can use the existing Mercury board. > > 73 Phil...VK6PH > > >> Hi Phil >> >> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >> that DFC was the way things were going. Which is why I jumped on the TK1 >> bandwagon. >> >> Will there ever be a way of using the Mercury front end to supply the raw >> packets, perhaps with a bespoke daughter board? >> >> Congrats to John whom I had the pleasure of speaking to at >> Friedrischafen. >> I'm sure we all look forward to the new era of SDR in the amateur radio >> arena. >> >> Cheers & 73 >> >> Chris G4NUX >> >> On 20 Aug 2014, at 08:31, Phil Harman wrote: >> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> All, >>> >>> I'm delighted to be able to report that we have been able to develop, to >>> proof-of-concept stage, a new SDR architecture. >>> >>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>> DDC, >>> in order to provide (multiple) receivers. Whist this is quite >>> effective, >>> much of the initial DSP work is done using FPGAs, or a combination of >>> FPGA >>> plus dedicated DSP chips and microprocessors, rather than totally within >>> the PC. >>> >>> As more complex features are added, the size and complexity of the FPGA >>> and DSP code increases. The skills to write, debug and maintain this >>> code >>> is only available via a small percentage of software engineers, or >>> enthusiasts, in comparison to those able to write code for PC based >>> hardware. >>> >>> In order to open the SDR world to those with PC software skills we are >>> in >>> the process of developing a new SDR architecture. >>> >>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>> time and passes the 'raw' samples directly to an associated computer. >>> >>> This computer then calculates the FFT of the raw samples and >>> subsequently >>> processes the result as the user requires. >>> >>> This is not a totally new concept since both the cuSDR and KISS Konsole >>> software uses raw ADC samples to provide the wideband bandscope >>> displays. >>> >>> However, for this requirement the FFT only needs to be done at the >>> bandscope update rate of a few 10's of times per second, which hardly >>> taxes a modern PC at all. >>> >>> The new concept requires that we take the FFT of all samples in >>> real-time. >>> >>> This has been possible in the past - if you had access to a Cray super >>> computer! >>> >>> Well now we do have access to very low cost computers that provide the >>> processing power we need. One example of this is the new Nvidia Jetson >>> TK1 single board computer. At a cost of $192 this board contains four >>> ARM >>> CPUs plus 192 CUDA processors. >>> >>> More details of this remarkable board can be found here: >>> >>> https://developer.nvidia.com/jetson-tk1 >>> >>> Since the CUDA cores can process data in parallel, we can use these to >>> perform the high speed FFT. >>> >>> John, G0ORX, has written preliminary code for the Jetson board and has >>> confirmed that it has the necessary performance we require. >>> >>> The test environment consisted of a Jetson board connected via Gigabit >>> Ethernet to an Angelia board. A special version of FPGA code was >>> written >>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>> the >>> Jetson board. >>> >>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>> >>> Whilst it's still early days, and there is much more to be done, this >>> critical early success does indicate that this new architecture has a >>> very >>> promising future. >>> >>> The Jetson board is taking the role of an 'SDR Server' which I have >>> written about in the past. >>> >>> In which case what benefits does this new architecture provide to >>> openHPSR? >>> >>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>> and hence uses a small percentage of the space available with a >>> subsequent >>> reduction in power consumption. >>> >>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>> simplified since the SDR hardware only has to connect to a single, >>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>> required. The SDR Server simply needs to know the MAC address of the >>> SDR >>> hardware in order to communicate. It should be possible for a single >>> SDR >>> hardware board to feed multiple SDR Servers, but that's something for >>> the >>> future. >>> >>> 3. Virtually all the signal processing is undertaken on the associated >>> single board computer (SBC) or (suitable) PC. If sufficient processing >>> power is available then the GUI can run on the same SBC. Alternatively >>> the >>> user's normal PC (which does not require to be high performance since it >>> does not do any significant digital signal processing) or a Tablet, cell >>> phone etc could be used. >>> >>> 4. Many more users have the necessary skills and experience to support, >>> maintain and further develop the code. New features are added to the SDR >>> Server code rather than the FPGA code. >>> >>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>> FPGA >>> and/or power supply restrictions may have limited adding new features. >>> >>> 6. Future hardware upgrades will be to the associated SBC where faster >>> and >>> lower cost options can be expected. Nvidia have already indicated that >>> a >>> 64 bit board will be available in the near future. >>> >>> 7. Remote access to an SDR via the Internet will enable multiple users >>> to >>> share the SDR with each selecting their desired frequency, bandwidth and >>> mode. >>> >>> There are other potential benefits relating to simpler and lower cost >>> SDR >>> hardware, but that is for the future. >>> >>> For want of a name we are calling this new architecture 'Direct Fourier >>> Conversion' (DFC). >>> >>> For those that are already experimenting with the Jetson board we do >>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>> and >>> I will advise when, and where, this is available. >>> >>> John's code is presently not available, so please don't pester him, but >>> as >>> soon as it reaches Beta stage it will be released. >>> >>> Please join me in congratulating John on this exciting development. >>> >>> 73 Phil....VK6PH >>> >>> >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: >>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> >> > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1408534651.0 From jeffrie at talktalk.net Wed Aug 20 06:25:58 2014 From: jeffrie at talktalk.net (Jeff Cook) Date: Wed, 20 Aug 2014 14:25:58 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <000001cfbc7a$47ce2d00$d76a8700$@talktalk.net> Hello Phil, As the epitome of what is an end user, button pusher, knob twiddler, et cetera, I readily admit to understanding little of which you speak, but your enthusiasm is infectious and your excitement palpable. I am still back in the days of Mercury and Ozymandias and love every minute of it, so thank you to you, and John, and all the others that are the true exponents of the radio art. It really is a pleasure being on board this particular magic of radio train, even though I have no idea where it's going. Jeff, G0AFQ. -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3vrf at johnc57uk.plus.com Wed Aug 20 06:54:16 2014 From: g3vrf at johnc57uk.plus.com (G3VRF) Date: Wed, 20 Aug 2014 14:54:16 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <53F4A888.10302@johnc57uk.plus.com> Hi Phil et al, Having been around in Ham radio for a good long while now, I have seen many changes and advancements in the hobby over the many years but none as exciting as this. I would like to echo Jeff's sentiments G0AFQ, and express how sincerely grateful I am to yourself Phil, and all the others who have contributed to the HPSDR project and from whom I've benefited. I have a Hermes board and homebrew low power PA which works extremely well and is a pleasure to use. In my view it easily out performs my Yaesu and Icom transceivers on receive. When I complete the high power PA it will no doubt out perfom on tx as well. I have earwigged on the side for a long while now monitoring developments and comments with interest. Next step is to purchase a Jetson TK1 SBC and attempt to build cuSDR on that. Again my heartfelt thanks. 73s John G3VRF 1408542856.0 From chris at vspl.co.uk Wed Aug 20 07:12:21 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 15:12:21 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> References: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> Message-ID: <20140820141226.1ED8248937@diego.dreamhost.com> Hi Phil Not sure you meant J5 - that seems to be the I2C data bypass jumper. J9 HDR 5P TEST seems to have some interesting/useful I/O pins. Is that what you meant? 73 Chris G4NUX On 20 Aug 2014, at 12:37, Phil Harman wrote: > Hi Chris. > > Alternatively, you could make a small PCB that plugged into J5 on Mercury that held the PHY, 25MHz clock and Ethernet socket. Since you no longer need any DDC code in the FPGA you would have plenty of room to house the raw Ethernet code. > > 'Weekend Project' anyone ? > > 73 Phil....VK6PH > > > > > > -----Original Message----- From: Chris Smith > Sent: Wednesday, August 20, 2014 4:48 PM > To: phil at pharman.org > Cc: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > Hi Phil > > I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) > > Cheers > > Chris > > > On 20 Aug 2014, at 09:22, "Phil Harman" wrote: > >> Hi Chris, >> >> The limitation of using the Mercury board together with Metis is the >> bandwidth of the Alex bus. >> >> If would could couple the two boards together in a suitable way then we >> can use the existing Mercury board. >> >> 73 Phil...VK6PH >> >> >>> Hi Phil >>> >>> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >>> that DFC was the way things were going. Which is why I jumped on the TK1 >>> bandwagon. >>> >>> Will there ever be a way of using the Mercury front end to supply the raw >>> packets, perhaps with a bespoke daughter board? >>> >>> Congrats to John whom I had the pleasure of speaking to at Friedrischafen. >>> I'm sure we all look forward to the new era of SDR in the amateur radio >>> arena. >>> >>> Cheers & 73 >>> >>> Chris G4NUX >>> >>> On 20 Aug 2014, at 08:31, Phil Harman wrote: >>> >>>> ***** High Performance Software Defined Radio Discussion List ***** >>>> >>>> All, >>>> >>>> I'm delighted to be able to report that we have been able to develop, to >>>> proof-of-concept stage, a new SDR architecture. >>>> >>>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>>> DDC, >>>> in order to provide (multiple) receivers. Whist this is quite >>>> effective, >>>> much of the initial DSP work is done using FPGAs, or a combination of >>>> FPGA >>>> plus dedicated DSP chips and microprocessors, rather than totally within >>>> the PC. >>>> >>>> As more complex features are added, the size and complexity of the FPGA >>>> and DSP code increases. The skills to write, debug and maintain this >>>> code >>>> is only available via a small percentage of software engineers, or >>>> enthusiasts, in comparison to those able to write code for PC based >>>> hardware. >>>> >>>> In order to open the SDR world to those with PC software skills we are >>>> in >>>> the process of developing a new SDR architecture. >>>> >>>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>>> time and passes the 'raw' samples directly to an associated computer. >>>> >>>> This computer then calculates the FFT of the raw samples and >>>> subsequently >>>> processes the result as the user requires. >>>> >>>> This is not a totally new concept since both the cuSDR and KISS Konsole >>>> software uses raw ADC samples to provide the wideband bandscope >>>> displays. >>>> >>>> However, for this requirement the FFT only needs to be done at the >>>> bandscope update rate of a few 10's of times per second, which hardly >>>> taxes a modern PC at all. >>>> >>>> The new concept requires that we take the FFT of all samples in >>>> real-time. >>>> >>>> This has been possible in the past - if you had access to a Cray super >>>> computer! >>>> >>>> Well now we do have access to very low cost computers that provide the >>>> processing power we need. One example of this is the new Nvidia Jetson >>>> TK1 single board computer. At a cost of $192 this board contains four >>>> ARM >>>> CPUs plus 192 CUDA processors. >>>> >>>> More details of this remarkable board can be found here: >>>> >>>> https://developer.nvidia.com/jetson-tk1 >>>> >>>> Since the CUDA cores can process data in parallel, we can use these to >>>> perform the high speed FFT. >>>> >>>> John, G0ORX, has written preliminary code for the Jetson board and has >>>> confirmed that it has the necessary performance we require. >>>> >>>> The test environment consisted of a Jetson board connected via Gigabit >>>> Ethernet to an Angelia board. A special version of FPGA code was >>>> written >>>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>>> the >>>> Jetson board. >>>> >>>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>>> >>>> Whilst it's still early days, and there is much more to be done, this >>>> critical early success does indicate that this new architecture has a >>>> very >>>> promising future. >>>> >>>> The Jetson board is taking the role of an 'SDR Server' which I have >>>> written about in the past. >>>> >>>> In which case what benefits does this new architecture provide to >>>> openHPSR? >>>> >>>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>>> and hence uses a small percentage of the space available with a >>>> subsequent >>>> reduction in power consumption. >>>> >>>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>>> simplified since the SDR hardware only has to connect to a single, >>>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>>> required. The SDR Server simply needs to know the MAC address of the >>>> SDR >>>> hardware in order to communicate. It should be possible for a single >>>> SDR >>>> hardware board to feed multiple SDR Servers, but that's something for >>>> the >>>> future. >>>> >>>> 3. Virtually all the signal processing is undertaken on the associated >>>> single board computer (SBC) or (suitable) PC. If sufficient processing >>>> power is available then the GUI can run on the same SBC. Alternatively >>>> the >>>> user's normal PC (which does not require to be high performance since it >>>> does not do any significant digital signal processing) or a Tablet, cell >>>> phone etc could be used. >>>> >>>> 4. Many more users have the necessary skills and experience to support, >>>> maintain and further develop the code. New features are added to the SDR >>>> Server code rather than the FPGA code. >>>> >>>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>>> FPGA >>>> and/or power supply restrictions may have limited adding new features. >>>> >>>> 6. Future hardware upgrades will be to the associated SBC where faster >>>> and >>>> lower cost options can be expected. Nvidia have already indicated that >>>> a >>>> 64 bit board will be available in the near future. >>>> >>>> 7. Remote access to an SDR via the Internet will enable multiple users >>>> to >>>> share the SDR with each selecting their desired frequency, bandwidth and >>>> mode. >>>> >>>> There are other potential benefits relating to simpler and lower cost >>>> SDR >>>> hardware, but that is for the future. >>>> >>>> For want of a name we are calling this new architecture 'Direct Fourier >>>> Conversion' (DFC). >>>> >>>> For those that are already experimenting with the Jetson board we do >>>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>>> and >>>> I will advise when, and where, this is available. >>>> >>>> John's code is presently not available, so please don't pester him, but >>>> as >>>> soon as it reaches Beta stage it will be released. >>>> >>>> Please join me in congratulating John on this exciting development. >>>> >>>> 73 Phil....VK6PH >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> HPSDR Discussion List >>>> To post msg: hpsdr at openhpsdr.org >>>> Subscription help: >>>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>>> HPSDR web page: http://openhpsdr.org >>>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >>> >>> >>> >> > > > --- > This email is free from viruses and malware because avast! Antivirus protection is active. > http://www.avast.com 1408543941.0 From chris at vspl.co.uk Wed Aug 20 07:19:06 2014 From: chris at vspl.co.uk (Chris Smith) Date: Wed, 20 Aug 2014 15:19:06 +0100 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <20140820141226.1ED8248937@diego.dreamhost.com> References: <36F1D4193B9A47C292DA7688B44865B9@ShackPC2> <20140820141226.1ED8248937@diego.dreamhost.com> Message-ID: <20140820141910.E5D7A489DF@diego.dreamhost.com> Whoops! No, I need to get some new glasses. J5 20-pin header has a whole bunch of good stuff on it. Sorry. 73 Chris G4NUX On 20 Aug 2014, at 15:12, Chris Smith wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Phil > > Not sure you meant J5 - that seems to be the I2C data bypass jumper. J9 HDR 5P TEST seems to have some interesting/useful I/O pins. Is that what you meant? > > 73 Chris G4NUX > > On 20 Aug 2014, at 12:37, Phil Harman wrote: > >> Hi Chris. >> >> Alternatively, you could make a small PCB that plugged into J5 on Mercury that held the PHY, 25MHz clock and Ethernet socket. Since you no longer need any DDC code in the FPGA you would have plenty of room to house the raw Ethernet code. >> >> 'Weekend Project' anyone ? >> >> 73 Phil....VK6PH >> >> >> >> >> >> -----Original Message----- From: Chris Smith >> Sent: Wednesday, August 20, 2014 4:48 PM >> To: phil at pharman.org >> Cc: hpsdr at lists.openhpsdr.org >> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >> >> Hi Phil >> >> I realised that the bottle-neck would be the Atlas backplane which is why I floated the idea of a bespoke daughter board for Mercury. Any control that Mercury needed could still be supplied by Atlas but the raw packets would be syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't remember the TLA for the gizmo - brain fade! :-) >> >> Cheers >> >> Chris >> >> >> On 20 Aug 2014, at 09:22, "Phil Harman" wrote: >> >>> Hi Chris, >>> >>> The limitation of using the Mercury board together with Metis is the >>> bandwidth of the Alex bus. >>> >>> If would could couple the two boards together in a suitable way then we >>> can use the existing Mercury board. >>> >>> 73 Phil...VK6PH >>> >>> >>>> Hi Phil >>>> >>>> I had a feeling, when I saw your paper and Hermann's at Friedrischafen, >>>> that DFC was the way things were going. Which is why I jumped on the TK1 >>>> bandwagon. >>>> >>>> Will there ever be a way of using the Mercury front end to supply the raw >>>> packets, perhaps with a bespoke daughter board? >>>> >>>> Congrats to John whom I had the pleasure of speaking to at Friedrischafen. >>>> I'm sure we all look forward to the new era of SDR in the amateur radio >>>> arena. >>>> >>>> Cheers & 73 >>>> >>>> Chris G4NUX >>>> >>>> On 20 Aug 2014, at 08:31, Phil Harman wrote: >>>> >>>>> ***** High Performance Software Defined Radio Discussion List ***** >>>>> >>>>> All, >>>>> >>>>> I'm delighted to be able to report that we have been able to develop, to >>>>> proof-of-concept stage, a new SDR architecture. >>>>> >>>>> Current SDRs use the software equivalent of zero IF techniques, i.e. >>>>> DDC, >>>>> in order to provide (multiple) receivers. Whist this is quite >>>>> effective, >>>>> much of the initial DSP work is done using FPGAs, or a combination of >>>>> FPGA >>>>> plus dedicated DSP chips and microprocessors, rather than totally within >>>>> the PC. >>>>> >>>>> As more complex features are added, the size and complexity of the FPGA >>>>> and DSP code increases. The skills to write, debug and maintain this >>>>> code >>>>> is only available via a small percentage of software engineers, or >>>>> enthusiasts, in comparison to those able to write code for PC based >>>>> hardware. >>>>> >>>>> In order to open the SDR world to those with PC software skills we are >>>>> in >>>>> the process of developing a new SDR architecture. >>>>> >>>>> This architecture digitises the entire 0 to 30MHz radio spectrum in real >>>>> time and passes the 'raw' samples directly to an associated computer. >>>>> >>>>> This computer then calculates the FFT of the raw samples and >>>>> subsequently >>>>> processes the result as the user requires. >>>>> >>>>> This is not a totally new concept since both the cuSDR and KISS Konsole >>>>> software uses raw ADC samples to provide the wideband bandscope >>>>> displays. >>>>> >>>>> However, for this requirement the FFT only needs to be done at the >>>>> bandscope update rate of a few 10's of times per second, which hardly >>>>> taxes a modern PC at all. >>>>> >>>>> The new concept requires that we take the FFT of all samples in >>>>> real-time. >>>>> >>>>> This has been possible in the past - if you had access to a Cray super >>>>> computer! >>>>> >>>>> Well now we do have access to very low cost computers that provide the >>>>> processing power we need. One example of this is the new Nvidia Jetson >>>>> TK1 single board computer. At a cost of $192 this board contains four >>>>> ARM >>>>> CPUs plus 192 CUDA processors. >>>>> >>>>> More details of this remarkable board can be found here: >>>>> >>>>> https://developer.nvidia.com/jetson-tk1 >>>>> >>>>> Since the CUDA cores can process data in parallel, we can use these to >>>>> perform the high speed FFT. >>>>> >>>>> John, G0ORX, has written preliminary code for the Jetson board and has >>>>> confirmed that it has the necessary performance we require. >>>>> >>>>> The test environment consisted of a Jetson board connected via Gigabit >>>>> Ethernet to an Angelia board. A special version of FPGA code was >>>>> written >>>>> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >>>>> the >>>>> Jetson board. >>>>> >>>>> We used raw Ethernet frames over the Gigabit link, in order to maximise >>>>> the link bandwidth, since we require a sustained 983Mbps transfer rate. >>>>> >>>>> Whilst it's still early days, and there is much more to be done, this >>>>> critical early success does indicate that this new architecture has a >>>>> very >>>>> promising future. >>>>> >>>>> The Jetson board is taking the role of an 'SDR Server' which I have >>>>> written about in the past. >>>>> >>>>> In which case what benefits does this new architecture provide to >>>>> openHPSR? >>>>> >>>>> 1. The FPGA code is greatly simplified, is easier to write and maintain, >>>>> and hence uses a small percentage of the space available with a >>>>> subsequent >>>>> reduction in power consumption. >>>>> >>>>> 2. The protocol between the SDR hardware and the SDR Server is greatly >>>>> simplified since the SDR hardware only has to connect to a single, >>>>> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >>>>> required. The SDR Server simply needs to know the MAC address of the >>>>> SDR >>>>> hardware in order to communicate. It should be possible for a single >>>>> SDR >>>>> hardware board to feed multiple SDR Servers, but that's something for >>>>> the >>>>> future. >>>>> >>>>> 3. Virtually all the signal processing is undertaken on the associated >>>>> single board computer (SBC) or (suitable) PC. If sufficient processing >>>>> power is available then the GUI can run on the same SBC. Alternatively >>>>> the >>>>> user's normal PC (which does not require to be high performance since it >>>>> does not do any significant digital signal processing) or a Tablet, cell >>>>> phone etc could be used. >>>>> >>>>> 4. Many more users have the necessary skills and experience to support, >>>>> maintain and further develop the code. New features are added to the SDR >>>>> Server code rather than the FPGA code. >>>>> >>>>> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >>>>> FPGA >>>>> and/or power supply restrictions may have limited adding new features. >>>>> >>>>> 6. Future hardware upgrades will be to the associated SBC where faster >>>>> and >>>>> lower cost options can be expected. Nvidia have already indicated that >>>>> a >>>>> 64 bit board will be available in the near future. >>>>> >>>>> 7. Remote access to an SDR via the Internet will enable multiple users >>>>> to >>>>> share the SDR with each selecting their desired frequency, bandwidth and >>>>> mode. >>>>> >>>>> There are other potential benefits relating to simpler and lower cost >>>>> SDR >>>>> hardware, but that is for the future. >>>>> >>>>> For want of a name we are calling this new architecture 'Direct Fourier >>>>> Conversion' (DFC). >>>>> >>>>> For those that are already experimenting with the Jetson board we do >>>>> intend to release the DFC FPGA code for both Angelia and Hermes boards >>>>> and >>>>> I will advise when, and where, this is available. >>>>> >>>>> John's code is presently not available, so please don't pester him, but >>>>> as >>>>> soon as it reaches Beta stage it will be released. >>>>> >>>>> Please join me in congratulating John on this exciting development. >>>>> >>>>> 73 Phil....VK6PH >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> HPSDR Discussion List >>>>> To post msg: hpsdr at openhpsdr.org >>>>> Subscription help: >>>>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>>>> HPSDR web page: http://openhpsdr.org >>>>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >>>> >>>> >>>> >>> >> >> >> --- >> This email is free from viruses and malware because avast! Antivirus protection is active. >> http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408544346.0 From mark at buttery.org Wed Aug 20 07:20:53 2014 From: mark at buttery.org (=?UTF-8?B?U2hpcmxleSBNw6FycXVleiBEw7psY2V5?=) Date: Wed, 20 Aug 2014 10:20:53 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <000001cfbc53$85bf7be0$913e73a0$@de> References: <000001cfbc53$85bf7be0$913e73a0$@de> Message-ID: > Congratulations. Maybe a stupid question: Current bottleneck is the 1 Gbit/s > LAN connection that makes a decimation by factor 2 necessary or limits the > frequency range to 33MHz, i.e. we lose 6m band at least as raw I/Q. Is > there no (economic) way to get the LAN connection faster? 14 and 16 Bit > ADC/DACs are getting faster and low-jitter sampling oscillators up to 300MHz > are available, hence a lot of nice applications are imaginable, hi. With the current boards there may not be. But a variety of standardized higher speed interfaces are available, including eSATA, Thunderbolt, USB 3.0, and 10G Ethernet. A future design could move to one of those. 1408544453.0 From meijer.ha at home.nl Wed Aug 20 08:29:00 2014 From: meijer.ha at home.nl (H.A.Meijer) Date: Wed, 20 Aug 2014 17:29:00 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> References: <53F46332.9040601@home.nl> <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> Message-ID: <53F4BEBC.9080105@home.nl> Hi Phil, So, just to simplify, so that I also understand, this Jetson board could replace (more or less) the on-board FPGA, being more powerful(?) and easier to code for the more 'average' software engineer?. And the (high performance) (W)DSP software, that's now running on or PC's, can easily by done by that board? and not just some very basic DSP work, I see at some 'other' popular sdr transceiver. The only problem I see for now is that there will be an extra 'data highway', between the sdr hardware and the end-user interface PC, that could coarse extra problems/latency..etc.. We will see what the future brings. Thanks, 73 Bert PA2XHF Phil Harman schreef op 20-8-2014 om 13:15: > Hi Bert, > Yes, as we are today the ?new board? is connected between your SDR > hardware and your PC. > It may be possible to run both the SDR server and Client GUI software > on the one SBC or PC. Its a little early yet to know if the Jetson > board is capable of doing this. > If so, then with your SDR hardware you would have a dedicated SDR that > does not require an additional PC. This could all be packaged into a > case with a suitable touch screen etc. > You can always do that today by using a suitable SBC that will run > Windows. > 73 Phil...VK6PH > > > > ------------------------------------------------------------------------ > --- Dit e-mailbericht bevat geen virussen en malware omdat avast! Antivirus-bescherming actief is. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dc6ny at gmx.de Wed Aug 20 10:55:20 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Wed, 20 Aug 2014 19:55:20 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <000001cfbc53$85bf7be0$913e73a0$@de> Message-ID: <000001cfbc9f$e8de2bd0$ba9a8370$@de> Thanks for reply, Mark. 73, Helmut -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von Shirley M?rquez D?lcey Gesendet: Mittwoch, 20. August 2014 16:21 An: hpsdr at lists.openhpsdr.org Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** > Congratulations. Maybe a stupid question: Current bottleneck is the 1 > Gbit/s LAN connection that makes a decimation by factor 2 necessary or > limits the frequency range to 33MHz, i.e. we lose 6m band at least as > raw I/Q. Is there no (economic) way to get the LAN connection faster? > 14 and 16 Bit ADC/DACs are getting faster and low-jitter sampling > oscillators up to 300MHz are available, hence a lot of nice applications are imaginable, hi. With the current boards there may not be. But a variety of standardized higher speed interfaces are available, including eSATA, Thunderbolt, USB 3.0, and 10G Ethernet. A future design could move to one of those. _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408557320.0 From doug at dougronald.com Wed Aug 20 11:22:33 2014 From: doug at dougronald.com (Doug Ronald) Date: Wed, 20 Aug 2014 11:22:33 -0700 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <007a01cfbca3$b7bfb880$273f2980$@dougronald.com> Hi, Could you give some idea of what is the present capability with regard to FFT's per second, and the bin size? I mean extracting from the information bandwidth for communications purposes, not simply for the frequency domain display. I'm curious to know if this would allow one to FFT over a 30 MHz bandwidth to say a 500 Hz bandwidth or even a 2.4 kHz bandwidth. That would be extremely useful. Thanks, -Doug Ronald AE6SY -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Phil Harman Sent: Wednesday, August 20, 2014 12:31 AM To: hpsdr at lists.openhpsdr.org Subject: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. In order to open the SDR world to those with PC software skills we are in the process of developing a new SDR architecture. This architecture digitises the entire 0 to 30MHz radio spectrum in real time and passes the 'raw' samples directly to an associated computer. This computer then calculates the FFT of the raw samples and subsequently processes the result as the user requires. This is not a totally new concept since both the cuSDR and KISS Konsole software uses raw ADC samples to provide the wideband bandscope displays. However, for this requirement the FFT only needs to be done at the bandscope update rate of a few 10's of times per second, which hardly taxes a modern PC at all. The new concept requires that we take the FFT of all samples in real-time. This has been possible in the past - if you had access to a Cray super computer! Well now we do have access to very low cost computers that provide the processing power we need. One example of this is the new Nvidia Jetson TK1 single board computer. At a cost of $192 this board contains four ARM CPUs plus 192 CUDA processors. More details of this remarkable board can be found here: https://developer.nvidia.com/jetson-tk1 Since the CUDA cores can process data in parallel, we can use these to perform the high speed FFT. John, G0ORX, has written preliminary code for the Jetson board and has confirmed that it has the necessary performance we require. The test environment consisted of a Jetson board connected via Gigabit Ethernet to an Angelia board. A special version of FPGA code was written for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the Jetson board. We used raw Ethernet frames over the Gigabit link, in order to maximise the link bandwidth, since we require a sustained 983Mbps transfer rate. Whilst it's still early days, and there is much more to be done, this critical early success does indicate that this new architecture has a very promising future. The Jetson board is taking the role of an 'SDR Server' which I have written about in the past. In which case what benefits does this new architecture provide to openHPSR? 1. The FPGA code is greatly simplified, is easier to write and maintain, and hence uses a small percentage of the space available with a subsequent reduction in power consumption. 2. The protocol between the SDR hardware and the SDR Server is greatly simplified since the SDR hardware only has to connect to a single, dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer required. The SDR Server simply needs to know the MAC address of the SDR hardware in order to communicate. It should be possible for a single SDR hardware board to feed multiple SDR Servers, but that's something for the future. 3. Virtually all the signal processing is undertaken on the associated single board computer (SBC) or (suitable) PC. If sufficient processing power is available then the GUI can run on the same SBC. Alternatively the user's normal PC (which does not require to be high performance since it does not do any significant digital signal processing) or a Tablet, cell phone etc could be used. 4. Many more users have the necessary skills and experience to support, maintain and further develop the code. New features are added to the SDR Server code rather than the FPGA code. 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA and/or power supply restrictions may have limited adding new features. 6. Future hardware upgrades will be to the associated SBC where faster and lower cost options can be expected. Nvidia have already indicated that a 64 bit board will be available in the near future. 7. Remote access to an SDR via the Internet will enable multiple users to share the SDR with each selecting their desired frequency, bandwidth and mode. There are other potential benefits relating to simpler and lower cost SDR hardware, but that is for the future. For want of a name we are calling this new architecture 'Direct Fourier Conversion' (DFC). For those that are already experimenting with the Jetson board we do intend to release the DFC FPGA code for both Angelia and Hermes boards and I will advise when, and where, this is available. John's code is presently not available, so please don't pester him, but as soon as it reaches Beta stage it will be released. Please join me in congratulating John on this exciting development. 73 Phil....VK6PH _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408558953.0 From jm-hpsdr at themarvins.org Wed Aug 20 12:57:07 2014 From: jm-hpsdr at themarvins.org (John Marvin) Date: Wed, 20 Aug 2014 13:57:07 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F4FD93.900@themarvins.org> I see no mention of the transmit side. I assume the current prototype (FPGA in particular) is a receive only implementation? Is DUC still the planned approach for transmit? I may get my 12 receivers (simultanous WSPR reception on all current and experimental ham bands 10m and below) on Hermes yet! Thanks for the update, John AC0ZG On 8/20/2014 1:31 AM, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408564627.0 From douglas.adams at me.com Wed Aug 20 17:11:51 2014 From: douglas.adams at me.com (Doug Adams) Date: Wed, 20 Aug 2014 20:11:51 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: Phil, This all sounds great, I'm all for advancing the "state-of-the-art". It would be great if an option was to have the SBC on a PCIE bus, that way it could be placed directly into a computer with such an interface (most PC's) or put into a PCIE Expansion box (e.g. a Mac expansion box fed by a Thunderbolt cable). That would get us a very high speed connection to the device and some OS independence. Does this also mean that the proposed changes to the Metis / Hermes protocol from the "Discussion Paper - openHPSDR Ethernet Protocol" are not going to be done? 73?s Doug - K3TZR -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at pharman.org Wed Aug 20 17:24:01 2014 From: phil at pharman.org (Phil Harman) Date: Thu, 21 Aug 2014 08:24:01 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F4FD93.900@themarvins.org> References: <53F4FD93.900@themarvins.org> Message-ID: <6226ab1d7b126fbb9ea9a51ba1e90654.squirrel@webmail.eftel.com.au> Hi John, Doing a similar approach for the transmitter is something for the future. If you only want 12 receivers then we can reduce it to that number :) 73 Phil... > ***** High Performance Software Defined Radio Discussion List ***** > > I see no mention of the transmit side. I assume the current prototype > (FPGA in particular) is a receive only implementation? Is DUC still the > planned approach for transmit? > > I may get my 12 receivers (simultanous WSPR reception on all current and > experimental ham bands 10m and below) on Hermes yet! > > Thanks for the update, > > John > AC0ZG > > On 8/20/2014 1:31 AM, Phil Harman wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> I'm delighted to be able to report that we have been able to develop, to >> proof-of-concept stage, a new SDR architecture. >> >> Current SDRs use the software equivalent of zero IF techniques, i.e. >> DDC, >> in order to provide (multiple) receivers. Whist this is quite >> effective, >> much of the initial DSP work is done using FPGAs, or a combination of >> FPGA >> plus dedicated DSP chips and microprocessors, rather than totally within >> the PC. >> >> As more complex features are added, the size and complexity of the FPGA >> and DSP code increases. The skills to write, debug and maintain this >> code >> is only available via a small percentage of software engineers, or >> enthusiasts, in comparison to those able to write code for PC based >> hardware. >> >> In order to open the SDR world to those with PC software skills we are >> in >> the process of developing a new SDR architecture. >> >> This architecture digitises the entire 0 to 30MHz radio spectrum in real >> time and passes the 'raw' samples directly to an associated computer. >> >> This computer then calculates the FFT of the raw samples and >> subsequently >> processes the result as the user requires. >> >> This is not a totally new concept since both the cuSDR and KISS Konsole >> software uses raw ADC samples to provide the wideband bandscope >> displays. >> >> However, for this requirement the FFT only needs to be done at the >> bandscope update rate of a few 10's of times per second, which hardly >> taxes a modern PC at all. >> >> The new concept requires that we take the FFT of all samples in >> real-time. >> >> This has been possible in the past - if you had access to a Cray super >> computer! >> >> Well now we do have access to very low cost computers that provide the >> processing power we need. One example of this is the new Nvidia Jetson >> TK1 single board computer. At a cost of $192 this board contains four >> ARM >> CPUs plus 192 CUDA processors. >> >> More details of this remarkable board can be found here: >> >> https://developer.nvidia.com/jetson-tk1 >> >> Since the CUDA cores can process data in parallel, we can use these to >> perform the high speed FFT. >> >> John, G0ORX, has written preliminary code for the Jetson board and has >> confirmed that it has the necessary performance we require. >> >> The test environment consisted of a Jetson board connected via Gigabit >> Ethernet to an Angelia board. A special version of FPGA code was >> written >> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to >> the >> Jetson board. >> >> We used raw Ethernet frames over the Gigabit link, in order to maximise >> the link bandwidth, since we require a sustained 983Mbps transfer rate. >> >> Whilst it's still early days, and there is much more to be done, this >> critical early success does indicate that this new architecture has a >> very >> promising future. >> >> The Jetson board is taking the role of an 'SDR Server' which I have >> written about in the past. >> >> In which case what benefits does this new architecture provide to >> openHPSR? >> >> 1. The FPGA code is greatly simplified, is easier to write and maintain, >> and hence uses a small percentage of the space available with a >> subsequent >> reduction in power consumption. >> >> 2. The protocol between the SDR hardware and the SDR Server is greatly >> simplified since the SDR hardware only has to connect to a single, >> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >> required. The SDR Server simply needs to know the MAC address of the >> SDR >> hardware in order to communicate. It should be possible for a single >> SDR >> hardware board to feed multiple SDR Servers, but that's something for >> the >> future. >> >> 3. Virtually all the signal processing is undertaken on the associated >> single board computer (SBC) or (suitable) PC. If sufficient processing >> power is available then the GUI can run on the same SBC. Alternatively >> the >> user's normal PC (which does not require to be high performance since it >> does not do any significant digital signal processing) or a Tablet, cell >> phone etc could be used. >> >> 4. Many more users have the necessary skills and experience to support, >> maintain and further develop the code. New features are added to the SDR >> Server code rather than the FPGA code. >> >> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >> FPGA >> and/or power supply restrictions may have limited adding new features. >> >> 6. Future hardware upgrades will be to the associated SBC where faster >> and >> lower cost options can be expected. Nvidia have already indicated that >> a >> 64 bit board will be available in the near future. >> >> 7. Remote access to an SDR via the Internet will enable multiple users >> to >> share the SDR with each selecting their desired frequency, bandwidth and >> mode. >> >> There are other potential benefits relating to simpler and lower cost >> SDR >> hardware, but that is for the future. >> >> For want of a name we are calling this new architecture 'Direct Fourier >> Conversion' (DFC). >> >> For those that are already experimenting with the Jetson board we do >> intend to release the DFC FPGA code for both Angelia and Hermes boards >> and >> I will advise when, and where, this is available. >> >> John's code is presently not available, so please don't pester him, but >> as >> soon as it reaches Beta stage it will be released. >> >> Please join me in congratulating John on this exciting development. >> >> 73 Phil....VK6PH >> >> >> >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > 1408580641.0 From wb4gcs at wb4gcs.org Wed Aug 20 17:37:23 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Wed, 20 Aug 2014 20:37:23 -0400 Subject: [hpsdr] Interesting email on SDR transmit noise In-Reply-To: <5261FFA0.8080001@tx.rr.com> References: <5261FFA0.8080001@tx.rr.com> Message-ID: <53F53F43.5010205@wb4gcs.org> WOW! Has anybody made similar measurements on Penny/Munim?? 73, Jim wb4gcs at amsat.org On 10/18/2013 11:42 PM, KA5FPT Paul wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I saw the following on the Flexradio mail list. I am having some > problems understanding how a SDR transmitter can cause wide band > noise. I would have thought that with proper filtering it would be > controlled. > ----------------------------------------------------------------------------------------------- > > > Date: Wed, 16 Oct 2013 14:59:37 -0400 > From: "Gedas" > To: > Subject: [Flexradio] Noise Sidebands, Article by SM5BSZ > Message-ID: <399ADD464530473F88C1CBF0659768F5 at biggy> > Content-Type: text/plain; charset="utf-8" > > I came across this interesting article by SM5BSZ who discusses some > possible transmitter issues with many radios, including the Flex. It > has me a bit concerned. I am wondering if anyone has seen similar > data for the Flex 5000? The article may be found here: > > http://www.sm5bsz.com/dynrange/dubus313.pdf > > Gedas, W8BYA > Gallery athttp://w8bya.com > Light travels faster than sound.... > This is why some people appear bright until you hear them speak. > > -------------------------------------------------------------------------------------------------- > > > 73, > Paul Cecil > KA5FPT > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1408581443.0 From phil at pharman.org Wed Aug 20 17:53:29 2014 From: phil at pharman.org (Phil Harman) Date: Thu, 21 Aug 2014 08:53:29 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F4BEBC.9080105@home.nl> References: <53F46332.9040601@home.nl> <24AFB337C4F1420FA3ABE2E361CDED8B@ShackPC2> <53F4BEBC.9080105@home.nl> Message-ID: Hi Bert, > So, just to simplify, so that I also understand, this Jetson board > could replace (more or less) the on-board FPGA, > being more powerful(?) and easier to code for the more 'average' > software engineer?. Yes, it does replace a large percentage of the FPGA code, not so sure about more powerful, but many more enthusiasts will be able to contribute. If there is enough spare capacity, or a future board has, then it could also replace the PC. > And the (high performance) (W)DSP software, that's now running on or > PC's, can easily by done by that board? > and not just some very basic DSP work, I see at some 'other' popular sdr > transceiver. Yes. > The only problem I see for now is that there will be an extra 'data > highway', between the sdr hardware > and the end-user interface PC, that could coarse extra > problems/latency..etc.. The data between the SDR Server and PC will only be low bandwidth. The Audio and bandscope data can be compressed so that we are perhaps only looking at 200kbps or even less. For digital modes it may be necessary to send I&Q data to the PC which will increase the bandwidth required. > We will see what the future brings. Yes, early days for DFC yet. We still have a lot to learn! 73 Phil...VK6PH 1408582409.0 From jm-hpsdr at themarvins.org Wed Aug 20 20:35:16 2014 From: jm-hpsdr at themarvins.org (John Marvin) Date: Wed, 20 Aug 2014 21:35:16 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <6226ab1d7b126fbb9ea9a51ba1e90654.squirrel@webmail.eftel.com.au> References: <53F4FD93.900@themarvins.org> <6226ab1d7b126fbb9ea9a51ba1e90654.squirrel@webmail.eftel.com.au> Message-ID: <53F568F4.3070204@themarvins.org> Oh, I'm quite aware that with this architecture the number of receivers is purely limited by the processing power and bandwidth you can apply to the problem. I look forward to playing with a fpga supporting this for Hermes. With this architecture it might make more sense for many use cases to do the I/O on the SBC (i.e. mike/line in and headphone/speaker out), but I hope that you will also preserve the capability of using the onboard Hermes I/O, i.e. still provide a synchronous mike stream with the single ultra wide data receive stream, and a synchronous speaker headphone channel, along with the control necessary to support them. Thanks, John On 8/20/2014 6:24 PM, Phil Harman wrote: > Hi John, > > Doing a similar approach for the transmitter is something for the future. > > If you only want 12 receivers then we can reduce it to that number :) > > 73 Phil... > > > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> I see no mention of the transmit side. I assume the current prototype >> (FPGA in particular) is a receive only implementation? Is DUC still the >> planned approach for transmit? >> >> I may get my 12 receivers (simultanous WSPR reception on all current and >> experimental ham bands 10m and below) on Hermes yet! >> >> Thanks for the update, >> >> John >> AC0ZG >> >> 1408592116.0 From lstoskopf at cox.net Thu Aug 21 07:55:49 2014 From: lstoskopf at cox.net (lstoskopf at cox.net) Date: Thu, 21 Aug 2014 10:55:49 -0400 Subject: [hpsdr] HackRF tutorial Message-ID: <20140821105549.YWEKY.153771.imail@eastrmwml106> Perhaps of interest: http://greatscottgadgets.com/sdr N0UU 1408632949.0 From peroy at broadpark.no Thu Aug 21 12:05:42 2014 From: peroy at broadpark.no (=?iso-8859-1?Q?=22Per_=D8yvind_Jonsson=22?=) Date: Thu, 21 Aug 2014 21:05:42 +0200 Subject: [hpsdr] Common Hermes firmware for Anan/Alex/Apollo? Message-ID: <77c0b3bd26a74.53f65f26@broadpark.no> First, thank you to the gurus for the fantastic effort with hardware, firmware and software! There is however one Hermes issue which begs to be solved, both to reduce user confusion, and hopefully also the effort needed to update the firmware. Today we need two Hermes FW versions. My understanding is that this is because the ANAN-10 and ALEX filters have different cut-off frequencies. It would of course be nice if Hermes could auto-detect which filter board is connected, but based on the schematics I have seen this will require some hardware modifications. Possible, but not desirable. When setting up PowerSDR we already need to specify the radio model, and some of this information is sent to Hermes. Would it be possible to extend this to also send information on which filter board is used? This could allow the FW to set the proper filter parameters. According to the USB_protocol_V1.58 there does not seem to be any bits that could be used directly, but it may be possible to use some otherwise unused combinations. One possibility seems to be to use C2 in the sequence starting with C0 = 0001001x, like this: bit 7: VNA mode (no change) bit 6: Alex manual (no change) bit 5: Hermes filter board (0 = Alex or ANAN, 1 = Apollo) bit 4-3-2: If bit 5 = 1 sets Apollo options (no change) If bit 5 = 0 could be used to specify which board(s) like so: 000 - None 001 - Alex RX 010 - Alex TX 011 - Alex RX+TX 100 - ANAN-10 other combinations available for future boards? bit 1: Metis/Penelope etc Mic/Line In (no change) bit 0: Hermes etc Mic Boost (no change) Thoughts/comments? LA9WX -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at foxgulch.com Fri Aug 22 09:41:09 2014 From: larry at foxgulch.com (Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop) Date: Fri, 22 Aug 2014 10:41:09 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> Message-ID: <53F772A5.9050001@foxgulch.com> Attempted to upgrade the firmware in my 100D using HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when I attempted to write 4.1 rbf, all operations stopped. Now it won't boot. (J17 jumper on or off, doesn't help) So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and fired off the Altera Quartus Programmer v12 build 177 11/7/2012 which responded after I clicked Start as follows: Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 2014 Info (209018): Device 1 silicon ID is 0x18 Info (209044): Erasing ASP configuration device(s) Info (209024): Programming device 1 Info (209018): Device 1 silicon ID is 0x18 Info (209011): Successfully performed operation(s) Info (209061): Ended Programmer operation at Fri Aug 22 15:26:15 2014 which looked OK but no boot! Second from left front panel red led glows constantly but dim. Somewhere I noticed (post by Franz Hegener) that I should have selected EPC 128? My device (in the Quartus II 32 bit Programmer window shows Device=EPCS16 as read from Quartus-II Programmer window and also shown in the document "Quartus-II Programmer and Byteblaster" by N9VV and KCXG v2.3 dated 04/23/13. Is this my error? Any ideas to try next?? Thanks, Larry W0AY Note for record: 1. Version 12 of the Quartus II Programmer matches the "Quartus-II Programmer and Byteblaster" instructions (noted above) but the current version V12 does not. Obtain V12 here: https://www.altera.com/download/sw/dnl-sw-index.jsp# 2. Win7 refused to load the drivers provided by Altera in V14. I used the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 1408725669.0 From k5so at valornet.com Fri Aug 22 10:20:32 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Fri, 22 Aug 2014 11:20:32 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: <53F772A5.9050001@foxgulch.com> References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: Hi Larry, Sorry to hear you?re having trouble programming your 100D. I suspect that when you first had your problem you could?ve recovered by using Bootloader mode, but perhaps something went awry. No problem, it?s all recoverable no matter what you did. Sounds like you have the Quartus II Programmer and your blaster cable talking fine to each other so you needn?t worry about trying to load v14 Quartus from Altera (in fact, I recommend not using v14). Here I use Quartus II v13.0 for most of my work but the Quartus II Programmer in v12 or likely any other earlier version will work to program an EEPROM config device so I wouldn?t worry about finding a particular version of Quartus II Programmer; it?s not that critical which you use, generally (at least in my experience). The Angelia board uses an EPCS128 EEPROM configuration device (not an EPCS16) so that is the device you should specify in the Quartus II Programmer. You should be plugging your blaster cable onto P2 and loading the file ?output_file.pof? for Angelia. The ?output_file.pof? contains both the bootloader code and the binary FPGA image that gets loaded later into the FPGA. If you erroneously load ?Angelia.pof? you will not be loading the bootloader code into the EEPROM with the FPGA image, you?ll only be loading the FPGA image. It will run and come up on power up but there is not bootloader code in it so should you later wish to use ?Bootloader? mode you cannot. Use the ?output_file.pof? to load into the EEPROM and you?ll be good. 73, Joe K5SO On Aug 22, 2014, at 10:41 AM, Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Attempted to upgrade the firmware in my 100D using HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when I attempted to write 4.1 rbf, all operations stopped. Now it won't boot. (J17 jumper on or off, doesn't help) > > So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and fired off the Altera Quartus Programmer v12 build 177 11/7/2012 which responded after I clicked Start as follows: > > Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 2014 > Info (209018): Device 1 silicon ID is 0x18 > Info (209044): Erasing ASP configuration device(s) > Info (209024): Programming device 1 > Info (209018): Device 1 silicon ID is 0x18 > Info (209011): Successfully performed operation(s) > Info (209061): Ended Programmer operation at Fri Aug 22 15:26:15 2014 > > which looked OK but no boot! Second from left front panel red led glows constantly but dim. > > Somewhere I noticed (post by Franz Hegener) that I should have selected EPC 128? My device (in the Quartus II 32 bit Programmer window shows Device=EPCS16 as read from Quartus-II Programmer window and also shown in the document "Quartus-II Programmer and Byteblaster" by N9VV and KCXG v2.3 dated 04/23/13. Is this my error? > > Any ideas to try next?? > > Thanks, > Larry W0AY > > Note for record: > 1. Version 12 of the Quartus II Programmer matches the "Quartus-II Programmer and Byteblaster" instructions (noted above) but the current version V12 does not. Obtain V12 here: https://www.altera.com/download/sw/dnl-sw-index.jsp# > > 2. Win7 refused to load the drivers provided by Altera in V14. I used the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408728032.0 From k5so at valornet.com Fri Aug 22 10:34:54 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Fri, 22 Aug 2014 11:34:54 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: <6CDCF9A3-A76E-4203-8939-984BA727DED3@valornet.com> Larry, One further comment, when loading an ?output_file.pof? into your Angelia it will power up with whatever firmware version number was used when the ?output_file.pof? was created. Therefore, after recovering using the blaster cable you will still need to update the firmware version to v4.1. If v4.1 happened to be used in creating the ?output_file.pof? then you do not need to update to v4.1 as it will already be loaded as part of the ?output_file.pof?. If you?re reluctant to try the update the Angelia using the HPSDRProgrammer the I?d suggest using the HPSDR Bootloader program instead, as it seems to be more robust (using a jumper on J17 during the update operation with HPSDR Bootloader, of course). The program you?d load using the HPSDR Bootloader is the same as you?d use with the HPSDR Programmer; namely, ?Angelia_v4.1.rbf?. 73, Joe K5SO 1408728894.0 From w5wc at windstream.net Fri Aug 22 10:43:04 2014 From: w5wc at windstream.net (Doug Wigley) Date: Fri, 22 Aug 2014 12:43:04 -0500 Subject: [hpsdr] PowerSDR/OpenHPSDR mRX PS v3.2.18 released Message-ID: <005601cfbe30$877604c0$96620e40$@net> All, PowerSDR/OpenHPSDR mRX PS v3.2.18 has been released. This is primarly a maintenace release which has a few bug fixes and feature enhancements added. The noteworthy changes are: - PowerSDR will check the database version being used on startup. If the databse was written by an older version of PowerSDR you will receive a warning and a choice to reset the database at that time. - Diversity values for the Reference Source, Gain, and Phase are saved and restored by band. - Diversity can now be enabled/disabled with the Diversity Form opened. - The PTT Control port can now use the same port as the CAT Control. This release can be downloaded from the openhpsdr.org website. http://openhpsdr.org/download.php 73, Doug W5WC 1408729384.0 From jkelly at verizon.net Fri Aug 22 13:12:28 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 22 Aug 2014 16:12:28 -0400 Subject: [hpsdr] FS - Band-pass filter Message-ID: Assembled Band-pass filter (BPF for SDR HERMES, ANAN-10 or HF transceiver) Similar to: http://www.ebay.com/itm/Band-pass-filter-BPF-for-SDR-HERMES-ANAN-10-or-HF-transceiver-/251578249143? $175. shipped CONUS. Jeff K2SDR -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkelly at verizon.net Fri Aug 22 14:22:37 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 22 Aug 2014 17:22:37 -0400 Subject: [hpsdr] FS - Band-pass filter In-Reply-To: References: Message-ID: <70FA5EC3B6604DCDB8E4102C084BD771@JeffPC> SOLD. Jeff From: Jeff Kelly Sent: Friday, August 22, 2014 16:12 To: hpsdr at openhpsdr.org Subject: [hpsdr] FS - Band-pass filter ***** High Performance Software Defined Radio Discussion List ***** -------------------------------------------------------------------------------- Assembled Band-pass filter (BPF for SDR HERMES, ANAN-10 or HF transceiver) Similar to: http://www.ebay.com/itm/Band-pass-filter-BPF-for-SDR-HERMES-ANAN-10-or-HF-transceiver-/251578249143? $175. shipped CONUS. Jeff K2SDR -------------------------------------------------------------------------------- _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From leskep at skymesh.com.au Fri Aug 22 16:12:40 2014 From: leskep at skymesh.com.au (Les Keppie) Date: Sat, 23 Aug 2014 09:12:40 +1000 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: <53F772A5.9050001@foxgulch.com> References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: Hi All I have experienced a similar situation regarding v4.1 whilst trying to revert to v4.0 After upgrading to v4.1 when it became available I only had it running for a short period when I was experiencing distorted audio - checked all bands same result - decided to revert to v4.0 firmware Using Programmer old file was reported as deleted but no perecntage values appeared when uploading the new file and the process never did complete I then switched to the Bootloader and again tried load v4.0 firmware - same result as using the Programmer This happened the day before I was due to go on 2 weeks holiday so just left everything as was On returning I thought about it for a while and decided to try the Bootloader and was able to upgrade to v4.1 and no distorted audio problems - have been running it now for some 4 days without any problems Just thought I would put this out for information Regards Les VK2DSG On Sat, 23 Aug 2014 02:41:09 +1000, Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Attempted to upgrade the firmware in my 100D using > HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when > I attempted to write 4.1 rbf, all operations stopped. Now it won't > boot. (J17 jumper on or off, doesn't help) > > So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and fired > off the Altera Quartus Programmer v12 build 177 11/7/2012 which > responded after I clicked Start as follows: > > Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 2014 > Info (209018): Device 1 silicon ID is 0x18 > Info (209044): Erasing ASP configuration device(s) > Info (209024): Programming device 1 > Info (209018): Device 1 silicon ID is 0x18 > Info (209011): Successfully performed operation(s) > Info (209061): Ended Programmer operation at Fri Aug 22 15:26:15 2014 > > which looked OK but no boot! Second from left front panel red led > glows constantly but dim. > > Somewhere I noticed (post by Franz Hegener) that I should have > selected EPC 128? My device (in the Quartus II 32 bit Programmer > window shows Device=EPCS16 as read from Quartus-II Programmer window and > also shown in the document "Quartus-II Programmer and Byteblaster" by > N9VV and KCXG v2.3 dated 04/23/13. Is this my error? > > Any ideas to try next?? > > Thanks, > Larry W0AY > > Note for record: > 1. Version 12 of the Quartus II Programmer matches the "Quartus-II > Programmer and Byteblaster" instructions (noted above) but the current > version V12 does not. Obtain V12 here: > https://www.altera.com/download/sw/dnl-sw-index.jsp# > > 2. Win7 refused to load the drivers provided by Altera in V14. I used > the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Using Opera's mail client: http://www.opera.com/mail/ 1408749160.0 From k5so at valornet.com Fri Aug 22 18:07:18 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Fri, 22 Aug 2014 19:07:18 -0600 Subject: [hpsdr] Angelia_v4.2 firmware release Message-ID: All, Angelia_v4.2 firmware is available for download from http://k5so.com/HPSDR_downloads.html This version of firmware slightly modifies the timing of v4.1 to make the design more robust with respect to running on many different Angelia boards. A few people have reported problems with v4.1 where one or more features became inoperable after 30 minutes or so of operation (e.g., CW sidetone simply stopping, etc). Most Angelia boards had no problem with v4.1 apparently but a few did. This v4.2 appears to have fixed those problems and appears to work fine on other Angelia boards too. I don?t know if the recently reported trouble experienced by a few people using HPSDR Programmer to update firmware in Angelia will be helped by this new firmware but it could, perhaps. In any case, should you run into trouble using HPSDR Programmer in the normal manner you should be able to use the HPSDR Bootloader program to recover. For those who wish to use the "brute force" method of completely reloading the Angelia EEPROM (including the bootloader code) by using a blaster cable with the Quartus II Programmer, I have created a new ?output_file.pof? file that includes both Angelia_v4.2 image and the bootloader code in it and I have included it in the zipped Angelia_v4.2 download folder. Using this ?output_file.pof? file will relieve you of the task of updating to v4.2 after loading the bootloader code, which you would need to do if you use an earlier version of ?output_file.pof? in your blaster cable process. Please keep in mind that you should not need to use a blaster cable to recover from a failed attempt to update firmware using HPSDR Programmer; recovery using HPSDR Bootloader (with J17 jumper in place, of course) should work for you in those (hopefully relatively rare!) cases. I included this new ?output_file.pof" file in the download folder only as a ?peace of mind? item and courtesy for those who like to use their blaster cables, hihi. 73, Joe K5SO 1408756038.0 From mlalonde at alphatronique.com Fri Aug 22 19:31:43 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Fri, 22 Aug 2014 22:31:43 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53F7FD0F.6020301@alphatronique.com> Hi guess some one already work on a ADC /DAC Board that go on the expansion connector of the DEV kit ? seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA as Glue logic.. that may remove the LAN / PHY from equation and permit made nice self contained platform ;-) if no one yet ,i may willing to help work on this ,i was a senior PCB designer whit some design backgrond .. Best 73! Marc VE2OLM On 20/08/2014 3:31 AM, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1408761103.0 From aa8k73 at gmail.com Fri Aug 22 19:43:52 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 22 Aug 2014 22:43:52 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/23 Message-ID: <53F7FFE8.3030108@gmail.com> The 23/Aug TeamSpeak mp3 (63 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3512 > or < http://www.hamsdr.com/dnld.aspx > Only silence truncation editing was done on this recording. Session text follows <20:35:08> *** You are now talking in channel: "OpenHPSDR" <21:06:29> "Bill - KD5TFD": needs better networking? <21:08:21> "Bill - KD5TFD": If he's an expert it's only an afternoon project <21:13:48> "Ken N9VV": CWSkimmer <21:18:15> "Warren - NR0V": < https://dl.dropboxusercontent.com/u/9282924/hpsdr/xcmaster.JPG > <21:28:04> "Ken N9VV": "Bonding" <21:28:32> "Bill - KD5TFD": 2 lane highway <21:28:56> "Jae - K5JAE": pci-e? <21:31:32> "Bill - KD5TFD": You mean I can't do 30 Mhz wide transmit? <21:32:20> "Bill - KD5TFD": light weight gui .. now that's an oxymoron <21:33:26> "Ken N9VV": Lightweight GUI = Android glSDR or HPSDR with Qt server doing all the work(?) <21:36:02> "Jae - K5JAE": FreeDV? <21:46:03> "Ken N9VV": K5SO released Angelia 4.2 tonight --- < http://k5so.com/Angelia_v4.2.zip > <21:47:46> "Bill - KD5TFD": anyone have a vnc server running on their Jetson? <21:51:50> "Jae - K5JAE": software is soft... hardware is hard :) <21:52:45> "Ken N9VV": SDRMAX = circa: 2004 according to N8VB Blog <21:55:56> "Rob - VE3EW": < http://www.iwavesystems.com/product/cpu-modules/cyclone-v-soc-qseven-som/altera-cyclone-v-soc-qseven-module.html > <21:57:12> "Bill - KD5TFD": awful lot of expertise in building a full blown computer board <21:57:43> "Bill - KD5TFD": an dcan you get it debugged in our lifetimes ... <22:05:12> "Bill - KD5TFD": dwim <22:05:27> "Bill - KD5TFD": dwim eax, edx <22:05:30> "Jae - K5JAE": is that called c#? 1408761832.0 From phil at pharman.org Fri Aug 22 20:31:13 2014 From: phil at pharman.org (Phil Harman) Date: Sat, 23 Aug 2014 11:31:13 +0800 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53F7FD0F.6020301@alphatronique.com> References: <53F7FD0F.6020301@alphatronique.com> Message-ID: <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Hi Marc, Thanks for your email. We still have a way to go with fully proving the DFC idea but so far its looking good. We actually had this discussion a few minutes ago during the weekly Teamspeak session. Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. If such a PCB design is of interest to you then please lets discuss further. 73 Phil....VK6PH -----Original Message----- From: Marc Lalonde Sent: Saturday, August 23, 2014 10:31 AM To: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Hi guess some one already work on a ADC /DAC Board that go on the expansion connector of the DEV kit ? seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA as Glue logic.. that may remove the LAN / PHY from equation and permit made nice self contained platform ;-) if no one yet ,i may willing to help work on this ,i was a senior PCB designer whit some design backgrond .. Best 73! Marc VE2OLM On 20/08/2014 3:31 AM, Phil Harman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within > the PC. > > As more complex features are added, the size and complexity of the FPGA > and DSP code increases. The skills to write, debug and maintain this code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. > > In order to open the SDR world to those with PC software skills we are in > the process of developing a new SDR architecture. > > This architecture digitises the entire 0 to 30MHz radio spectrum in real > time and passes the 'raw' samples directly to an associated computer. > > This computer then calculates the FFT of the raw samples and subsequently > processes the result as the user requires. > > This is not a totally new concept since both the cuSDR and KISS Konsole > software uses raw ADC samples to provide the wideband bandscope displays. > > However, for this requirement the FFT only needs to be done at the > bandscope update rate of a few 10's of times per second, which hardly > taxes a modern PC at all. > > The new concept requires that we take the FFT of all samples in real-time. > > This has been possible in the past - if you had access to a Cray super > computer! > > Well now we do have access to very low cost computers that provide the > processing power we need. One example of this is the new Nvidia Jetson > TK1 single board computer. At a cost of $192 this board contains four ARM > CPUs plus 192 CUDA processors. > > More details of this remarkable board can be found here: > > https://developer.nvidia.com/jetson-tk1 > > Since the CUDA cores can process data in parallel, we can use these to > perform the high speed FFT. > > John, G0ORX, has written preliminary code for the Jetson board and has > confirmed that it has the necessary performance we require. > > The test environment consisted of a Jetson board connected via Gigabit > Ethernet to an Angelia board. A special version of FPGA code was written > for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the > Jetson board. > > We used raw Ethernet frames over the Gigabit link, in order to maximise > the link bandwidth, since we require a sustained 983Mbps transfer rate. > > Whilst it's still early days, and there is much more to be done, this > critical early success does indicate that this new architecture has a very > promising future. > > The Jetson board is taking the role of an 'SDR Server' which I have > written about in the past. > > In which case what benefits does this new architecture provide to > openHPSR? > > 1. The FPGA code is greatly simplified, is easier to write and maintain, > and hence uses a small percentage of the space available with a subsequent > reduction in power consumption. > > 2. The protocol between the SDR hardware and the SDR Server is greatly > simplified since the SDR hardware only has to connect to a single, > dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer > required. The SDR Server simply needs to know the MAC address of the SDR > hardware in order to communicate. It should be possible for a single SDR > hardware board to feed multiple SDR Servers, but that's something for the > future. > > 3. Virtually all the signal processing is undertaken on the associated > single board computer (SBC) or (suitable) PC. If sufficient processing > power is available then the GUI can run on the same SBC. Alternatively the > user's normal PC (which does not require to be high performance since it > does not do any significant digital signal processing) or a Tablet, cell > phone etc could be used. > > 4. Many more users have the necessary skills and experience to support, > maintain and further develop the code. New features are added to the SDR > Server code rather than the FPGA code. > > 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA > and/or power supply restrictions may have limited adding new features. > > 6. Future hardware upgrades will be to the associated SBC where faster and > lower cost options can be expected. Nvidia have already indicated that a > 64 bit board will be available in the near future. > > 7. Remote access to an SDR via the Internet will enable multiple users to > share the SDR with each selecting their desired frequency, bandwidth and > mode. > > There are other potential benefits relating to simpler and lower cost SDR > hardware, but that is for the future. > > For want of a name we are calling this new architecture 'Direct Fourier > Conversion' (DFC). > > For those that are already experimenting with the Jetson board we do > intend to release the DFC FPGA code for both Angelia and Hermes boards and > I will advise when, and where, this is available. > > John's code is presently not available, so please don't pester him, but as > soon as it reaches Beta stage it will be released. > > Please join me in congratulating John on this exciting development. > > 73 Phil....VK6PH > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1408764673.0 From rick at teksharp.com Sat Aug 23 06:20:21 2014 From: rick at teksharp.com (Rick Fletcher) Date: Sat, 23 Aug 2014 07:20:21 -0600 Subject: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable In-Reply-To: References: <829A2C02-F826-4E31-9E8A-C389DA4B0E99@franz-hegener.de> <8869A25A-D8BD-4C89-9FBF-F9EE83AFC0FB@franz-hegener.de> <53F772A5.9050001@foxgulch.com> Message-ID: <00ef01cfbed5$0b5c8d00$2215a700$@teksharp.com> I'm still running V3.5 and have experienced distorted audio twice. Both times, I was able to restore normal operation by terminating PowerSDR and launching a new instance of it. 73, Rick, W7YP -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Les Keppie Sent: Friday, August 22, 2014 5:13 PM To: larry at foxgulch.com; hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] Bricked my Angelia: Help installing Bootloader using USB Blaster cable ***** High Performance Software Defined Radio Discussion List ***** Hi All I have experienced a similar situation regarding v4.1 whilst trying to revert to v4.0 After upgrading to v4.1 when it became available I only had it running for a short period when I was experiencing distorted audio - checked all bands same result - decided to revert to v4.0 firmware Using Programmer old file was reported as deleted but no perecntage values appeared when uploading the new file and the process never did complete I then switched to the Bootloader and again tried load v4.0 firmware - same result as using the Programmer This happened the day before I was due to go on 2 weeks holiday so just left everything as was On returning I thought about it for a while and decided to try the Bootloader and was able to upgrade to v4.1 and no distorted audio problems - have been running it now for some 4 days without any problems Just thought I would put this out for information Regards Les VK2DSG On Sat, 23 Aug 2014 02:41:09 +1000, Larry J on Linux Mint 17 (Ubuntu 14.04) Desktop wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Attempted to upgrade the firmware in my 100D using > HPSDRProgrammer_V2_nopcap 2.0. Board was intially discovered but when > I attempted to write 4.1 rbf, all operations stopped. Now it won't > boot. (J17 jumper on or off, doesn't help) > > So I hooked up my Canton Electronics "Altera USBBlaster Rev C) and > fired off the Altera Quartus Programmer v12 build 177 11/7/2012 which > responded after I clicked Start as follows: > > Info (209060): Started Programmer operation at Fri Aug 22 15:25:23 > 2014 Info (209018): Device 1 silicon ID is 0x18 Info (209044): Erasing > ASP configuration device(s) Info (209024): Programming device 1 Info > (209018): Device 1 silicon ID is 0x18 Info (209011): Successfully > performed operation(s) Info (209061): Ended Programmer operation at > Fri Aug 22 15:26:15 2014 > > which looked OK but no boot! Second from left front panel red led > glows constantly but dim. > > Somewhere I noticed (post by Franz Hegener) that I should have > selected EPC 128? My device (in the Quartus II 32 bit Programmer > window shows Device=EPCS16 as read from Quartus-II Programmer window > and also shown in the document "Quartus-II Programmer and Byteblaster" by > N9VV and KCXG v2.3 dated 04/23/13. Is this my error? > > Any ideas to try next?? > > Thanks, > Larry W0AY > > Note for record: > 1. Version 12 of the Quartus II Programmer matches the "Quartus-II > Programmer and Byteblaster" instructions (noted above) but the current > version V12 does not. Obtain V12 here: > https://www.altera.com/download/sw/dnl-sw-index.jsp# > > 2. Win7 refused to load the drivers provided by Altera in V14. I used > the USB Blaster drivers by Altera dated 2/17/2009 version 2.4.16.0 > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Using Opera's mail client: http://www.opera.com/mail/ _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408800021.0 From mlalonde at alphatronique.com Sat Aug 23 06:42:14 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Sat, 23 Aug 2014 09:42:14 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <53F89A36.4070905@alphatronique.com> Hi Phil, After some quick reading it seems that ePCI bus is Point to Point (no need for southBridge) It may sure be a good idea and let option to upgrade the Nvidia card later as tech advance. My work schedule have a bit more room on September so if there is need I will be happy to jump in. Best 73! On 22/08/2014 11:31 PM, Phil Harman wrote: > Hi Marc, > > Thanks for your email. > > We still have a way to go with fully proving the DFC idea but so far > its looking good. > > We actually had this discussion a few minutes ago during the weekly > Teamspeak session. > > Whilst the GPIO is one solution our concern is that the Jetson board > is not going to be a production item for Nvidia. There is no > guarantee that what board replaces it, be it 64 bit Jeston or > something completely different, may not have the same GIPO port. > > What does look viable is a board using miniPCIe since there is a > good possibility that future SBCs will carry this interface. > > What was suggested was a miniPCIe board with an Altera Cyclone V FPGA > (since this has PCIe implement in hardware on the chip) plus an ADC, > DAC and I/O. The I/O could include an interface to the Alex board so > we can use that rather than reproduce that hardware. > > With an FPGA on the board we have many options from DFC down to > porting the existing DDC/DUC code, which is all ready proven to work. > > If such a PCB design is of interest to you then please lets discuss > further. > > 73 Phil....VK6PH > > > > > -----Original Message----- From: Marc Lalonde > Sent: Saturday, August 23, 2014 10:31 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > guess some one already work on a ADC /DAC Board that go on the expansion > connector of the DEV kit ? > seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA > as Glue logic.. > > that may remove the LAN / PHY from equation and permit made nice self > contained platform ;-) > > if no one yet ,i may willing to help work on this ,i was a senior PCB > designer whit some design backgrond .. > > Best 73! > Marc VE2OLM > > On 20/08/2014 3:31 AM, Phil Harman wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> I'm delighted to be able to report that we have been able to develop, to >> proof-of-concept stage, a new SDR architecture. >> >> Current SDRs use the software equivalent of zero IF techniques, i.e. >> DDC, >> in order to provide (multiple) receivers. Whist this is quite >> effective, >> much of the initial DSP work is done using FPGAs, or a combination of >> FPGA >> plus dedicated DSP chips and microprocessors, rather than totally within >> the PC. >> >> As more complex features are added, the size and complexity of the FPGA >> and DSP code increases. The skills to write, debug and maintain this >> code >> is only available via a small percentage of software engineers, or >> enthusiasts, in comparison to those able to write code for PC based >> hardware. >> >> In order to open the SDR world to those with PC software skills we >> are in >> the process of developing a new SDR architecture. >> >> This architecture digitises the entire 0 to 30MHz radio spectrum in real >> time and passes the 'raw' samples directly to an associated computer. >> >> This computer then calculates the FFT of the raw samples and >> subsequently >> processes the result as the user requires. >> >> This is not a totally new concept since both the cuSDR and KISS Konsole >> software uses raw ADC samples to provide the wideband bandscope >> displays. >> >> However, for this requirement the FFT only needs to be done at the >> bandscope update rate of a few 10's of times per second, which hardly >> taxes a modern PC at all. >> >> The new concept requires that we take the FFT of all samples in >> real-time. >> >> This has been possible in the past - if you had access to a Cray super >> computer! >> >> Well now we do have access to very low cost computers that provide the >> processing power we need. One example of this is the new Nvidia Jetson >> TK1 single board computer. At a cost of $192 this board contains >> four ARM >> CPUs plus 192 CUDA processors. >> >> More details of this remarkable board can be found here: >> >> https://developer.nvidia.com/jetson-tk1 >> >> Since the CUDA cores can process data in parallel, we can use these to >> perform the high speed FFT. >> >> John, G0ORX, has written preliminary code for the Jetson board and has >> confirmed that it has the necessary performance we require. >> >> The test environment consisted of a Jetson board connected via Gigabit >> Ethernet to an Angelia board. A special version of FPGA code was >> written >> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps >> to the >> Jetson board. >> >> We used raw Ethernet frames over the Gigabit link, in order to maximise >> the link bandwidth, since we require a sustained 983Mbps transfer rate. >> >> Whilst it's still early days, and there is much more to be done, this >> critical early success does indicate that this new architecture has a >> very >> promising future. >> >> The Jetson board is taking the role of an 'SDR Server' which I have >> written about in the past. >> >> In which case what benefits does this new architecture provide to >> openHPSR? >> >> 1. The FPGA code is greatly simplified, is easier to write and maintain, >> and hence uses a small percentage of the space available with a >> subsequent >> reduction in power consumption. >> >> 2. The protocol between the SDR hardware and the SDR Server is greatly >> simplified since the SDR hardware only has to connect to a single, >> dedicated, SBC or PC. Hence ARP, DHCP, ping, UDP/IP etc are no longer >> required. The SDR Server simply needs to know the MAC address of the >> SDR >> hardware in order to communicate. It should be possible for a single >> SDR >> hardware board to feed multiple SDR Servers, but that's something for >> the >> future. >> >> 3. Virtually all the signal processing is undertaken on the associated >> single board computer (SBC) or (suitable) PC. If sufficient processing >> power is available then the GUI can run on the same SBC. >> Alternatively the >> user's normal PC (which does not require to be high performance since it >> does not do any significant digital signal processing) or a Tablet, cell >> phone etc could be used. >> >> 4. Many more users have the necessary skills and experience to support, >> maintain and further develop the code. New features are added to the SDR >> Server code rather than the FPGA code. >> >> 5. Extends the useful life of openHPSDR Hermes boards where otherwise >> FPGA >> and/or power supply restrictions may have limited adding new features. >> >> 6. Future hardware upgrades will be to the associated SBC where >> faster and >> lower cost options can be expected. Nvidia have already indicated >> that a >> 64 bit board will be available in the near future. >> >> 7. Remote access to an SDR via the Internet will enable multiple >> users to >> share the SDR with each selecting their desired frequency, bandwidth and >> mode. >> >> There are other potential benefits relating to simpler and lower cost >> SDR >> hardware, but that is for the future. >> >> For want of a name we are calling this new architecture 'Direct Fourier >> Conversion' (DFC). >> >> For those that are already experimenting with the Jetson board we do >> intend to release the DFC FPGA code for both Angelia and Hermes >> boards and >> I will advise when, and where, this is available. >> >> John's code is presently not available, so please don't pester him, >> but as >> soon as it reaches Beta stage it will be released. >> >> Please join me in congratulating John on this exciting development. >> >> 73 Phil....VK6PH >> >> >> >> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > 1408801334.0 From sbdick at optonline.net Sat Aug 23 08:13:24 2014 From: sbdick at optonline.net (Steven B. Dick) Date: Sat, 23 Aug 2014 11:13:24 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: Phil, as you indicated, The skills to write, debug and maintain FPGA code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. This has been a major problem in industry for years, as the cost per "line of code" is much higher for firmware vs. software for code development and maintenance, on the order of a factor of perhaps 10 to 1 for FPGA firmware vs. software written in a high order language. Note that tools such as MATLAB can be used to develop FPGA code directly rather than hand coding verilog or VHDL code but are not low cost tools. Another approach to consider is the newly emerging FPGA vendor support of high order "graphics" programming languages for their latest "System on a chip" FPGAs. Both Altera and Xilinx are now beginning to support the OpenCL programming language for their FPGAs using their latest toolsets. OpenCL is not proprietary vs. CUDA which is tied in with NVIDIA. CUDA is more mature and has a more extensive set of available libraries and a larger user community however. Although programming with OpenCL on an FPGA vs. a graphics chip using multiple graphics processing engines requires different programming approaches to take best advantages of the underlying hardware resources, this may be a way to program for "System on a chip" FPGAs, strictly in software though maintining a mix of hardware and software resources, including multiple ARM processors. Regards. "Digital Steve", K1RF -----Original Message----- All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. *********************** 1408806804.0 From rcrewson at cinci.rr.com Sat Aug 23 09:26:41 2014 From: rcrewson at cinci.rr.com (Rob Crewson) Date: Sat, 23 Aug 2014 12:26:41 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> Hi Steve, I have been looking OpenCL for a couple of months by taking some online courses. Of note is that NVidia also belongs and supports the consortium. Unfortunately in the last one of the series (just watched it today ), it mentions that a fully licensed of QuartusII is needed in order to actually get compiled code generated and loaded on a FPGA. I did not check the development board costs at that point but they are licensed for a fee as well. 73, Rob Crewson - VE3EW -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Steven B. Dick Sent: Saturday, August 23, 2014 11:13 AM To: hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Phil, as you indicated, The skills to write, debug and maintain FPGA code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. This has been a major problem in industry for years, as the cost per "line of code" is much higher for firmware vs. software for code development and maintenance, on the order of a factor of perhaps 10 to 1 for FPGA firmware vs. software written in a high order language. Note that tools such as MATLAB can be used to develop FPGA code directly rather than hand coding verilog or VHDL code but are not low cost tools. Another approach to consider is the newly emerging FPGA vendor support of high order "graphics" programming languages for their latest "System on a chip" FPGAs. Both Altera and Xilinx are now beginning to support the OpenCL programming language for their FPGAs using their latest toolsets. OpenCL is not proprietary vs. CUDA which is tied in with NVIDIA. CUDA is more mature and has a more extensive set of available libraries and a larger user community however. Although programming with OpenCL on an FPGA vs. a graphics chip using multiple graphics processing engines requires different programming approaches to take best advantages of the underlying hardware resources, this may be a way to program for "System on a chip" FPGAs, strictly in software though maintining a mix of hardware and software resources, including multiple ARM processors. Regards. "Digital Steve", K1RF -----Original Message----- All, I'm delighted to be able to report that we have been able to develop, to proof-of-concept stage, a new SDR architecture. Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, in order to provide (multiple) receivers. Whist this is quite effective, much of the initial DSP work is done using FPGAs, or a combination of FPGA plus dedicated DSP chips and microprocessors, rather than totally within the PC. As more complex features are added, the size and complexity of the FPGA and DSP code increases. The skills to write, debug and maintain this code is only available via a small percentage of software engineers, or enthusiasts, in comparison to those able to write code for PC based hardware. *********************** _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408811201.0 From k5so at valornet.com Sat Aug 23 11:06:14 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sat, 23 Aug 2014 12:06:14 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> Message-ID: <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> A personal comment regarding FPGA programming and programming in general: The view that writing and maintaining FPGA code is beyond the capability of most of us has been blown completely out of proportion to reality! That view is simply incorrect. Indeed, I?m a good example of the point, I think. As many of you know, I am certainly not a professional programmer and, in fact, I have had no serious programming experience at all in any computer language in my life. Since joining the HPSDR community a few years ago I have managed to muddle my way along in learning how to successfully write both FPGA code and PowerSDR (C# and C) code and have discovered that it simply isn?t that hard to do. I readily admit that my code isn?t ?elegant? in the purist view but it works (sometimes anyway, hihi). The point I?m trying to make is that you only have to be willing to learn something new, that?s all, and not be too timid to give it a try to ultimately become successful in doing ANY of the programming we do. Indeed, it turns out that even the often-viewed-as-no-man?s-land of timing FPGA designs is actually completely accessible to non-professionals such as we are and, in fact, the task is easily within the grasp of the average experimenter. Further, we have always used and are still using free versions of Quartus II to create FPGA designs and load the FPGAs without problem. You don?t have to have the fully licensed Quartus II versions to do anything we wish to do with these FPGAs. Counter to what one might assume from the recent discussions, any of us can do FPGA programming with the free tools we have available from Altera if you only care to put the effort into learning how to do it. It just isn?t that hard! I?m certainly no expert in any of this stuff and would never claim to be but you don?t have to be an expert to be able to learn to work with these tools and be able to make meaningful contributions. There is no reason at all that only a small percentage of our group can do FPGA programming! The truth is that anyone can do it if you set your mind to do it. 73, Joe K5SO On Aug 23, 2014, at 10:26 AM, Rob Crewson wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Steve, > > I have been looking OpenCL for a couple of months by taking some online > courses. > Of note is that NVidia also belongs and supports the consortium. > > Unfortunately in the last one of the series (just watched it today ), it > mentions that a fully licensed of QuartusII > is needed in order to actually get compiled code generated and loaded on > a FPGA. > > I did not check the development board costs at that point but they are > licensed for a fee as well. > > 73, > > Rob Crewson - VE3EW > > > > -----Original Message----- > From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Steven > B. Dick > Sent: Saturday, August 23, 2014 11:13 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > ***** High Performance Software Defined Radio Discussion List ***** > > Phil, as you indicated, The skills to write, debug and maintain FPGA code > is only available via a small percentage of software engineers, or > enthusiasts, in comparison to those able to write code for PC based > hardware. This has been a major problem in industry for years, as the cost > per "line of code" is much higher for firmware vs. software for code > development and maintenance, on the order of a factor of perhaps 10 to 1 for > FPGA firmware vs. software written in a high order language. Note that > tools such as MATLAB can be used to develop FPGA code directly rather than > hand coding verilog or VHDL code but are not low cost tools. > > Another approach to consider is the newly emerging FPGA vendor support of > high order "graphics" programming languages for their latest "System on a > chip" FPGAs. Both Altera and Xilinx are now beginning to support the OpenCL > programming language for their FPGAs using their latest toolsets. OpenCL is > not proprietary vs. CUDA which is tied in with NVIDIA. CUDA is more mature > and has a more extensive set of available libraries and a larger user > community however. Although programming with OpenCL on an FPGA vs. a > graphics chip using multiple graphics processing engines requires different > programming approaches to take best advantages of the underlying hardware > resources, this may be a way to program for "System on a chip" FPGAs, > strictly in software though maintining a mix of hardware and software > resources, including multiple ARM processors. > > Regards. "Digital Steve", K1RF > > -----Original Message----- > All, > > I'm delighted to be able to report that we have been able to develop, to > proof-of-concept stage, a new SDR architecture. > > Current SDRs use the software equivalent of zero IF techniques, i.e. DDC, > in order to provide (multiple) receivers. Whist this is quite effective, > much of the initial DSP work is done using FPGAs, or a combination of FPGA > plus dedicated DSP chips and microprocessors, rather than totally within the > PC. > > As more complex features are added, the size and complexity of the FPGA and > DSP code increases. The skills to write, debug and maintain this code is > only available via a small percentage of software engineers, or enthusiasts, > in comparison to those able to write code for PC based hardware. > > *********************** > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408817174.0 From sbdick at optonline.net Sat Aug 23 12:10:10 2014 From: sbdick at optonline.net (Steven B. Dick) Date: Sat, 23 Aug 2014 15:10:10 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> Message-ID: <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with a desire to learn and my hat is off to you for taking it upon yourself to learn both firmware and software programming. That was not the point I was trying to make. In my previous life, I was a digital design manager. FPGA code designed by experienced senior FPGA designers took a lot more time to develop (even worse to maintain) compared to software written by experienced software developers which ran on general purpose compute nodes. For many years, FPGA designs had an important role to play where special functions just could not be done in general purpose processors or even DSP processors with comparable performance, but one willingly paid for it in reaping the benefits of high performance and/or greatly reduced hardware footprint. But the processing landscape is changing nowadays with very low cost processing platforms based on multiple node graphics engines coupled with high order language support with DSP libraries. Use of these platforms is starting to result in huge performance capabilities in a low cost rapid development environment if these platforms can be readily used for particular applications including the FFT function. Regards, "Digital Steve", K1RF -----Original Message----- From: Joe Martin K5SO [mailto:k5so at valornet.com] Sent: Saturday, August 23, 2014 2:06 PM To: Rob Crewson Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development A personal comment regarding FPGA programming and programming in general: The view that writing and maintaining FPGA code is beyond the capability of most of us has been blown completely out of proportion to reality! That view is simply incorrect. Indeed, I'm a good example of the point, I think. 1408821010.0 From k5so at valornet.com Sat Aug 23 12:23:43 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sat, 23 Aug 2014 13:23:43 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> Message-ID: <260DD696-CE58-4F14-A24E-55B5FFCCDC3F@valornet.com> There are many such sources for information. To learn the basics of the Verilog language, which is what we use to write the FPGA code designs, Kirk Weedman KD7IRS some years ago kindly put together a beginners course tailored to the HPSDR project. The course is available for download on the HPSDR webpage below: http://verilog.openhpsdr.org However, in my experience the absolute best way to learn how to do this is by downloading Quartus II, installing it on your computer, and using it to examine an existing HPSDR firmware design. By examing an actual firmware design that we are using today you can see how the various tasks are accomplished in the code. We try to comment the code as much as is practical in order to help us remember what each section does but also to help newcomers understand what the code section is doing. You can spend lots of unnecessary time attending/viewing classes which will be giving you much info regarding Verilog syntax, etc, but you can also get the idea very quickly by examining an actual firmware design by using the Quartus II editor. In addition, you?ll immediately be learning how to use the Quartus II tool. In short, my view that the absolute best way to learn is to get your feet wet immediately with the tool that you will be using; i.e., Quartus II, to examine an existing firmware design. The primary issue to understand about FPGA code, in my view, is to realize from the start that each little section of code within the firmware design runs in parallel with every other section. That is, the code execution is not ?event driven? as it is in Windows programming nor is it strictly running lines of code sequentially as in some languages (except within each section of code in the firmare design). Because of this it is actually easy to take one little section of code and examine it carefully to see what it is doing, how it is doing it, and what syntax is used to accomplish it. After you feel you understand a portion of it then you can make small changes to it, compile it, and see what effect your change(s) have on the performance of the firmware design by actually loading it into your HPSDR rigs? FPGA. Plus you immediately gain experience in how to do all that. Sure, you?ll make mistakes! But be assured that anything you do is recoverable; you can?t hurt the FPGA by misprogramming it. 73, Joe K5SO On Aug 23, 2014, at 12:46 PM, Neal Campbell wrote: > Are there any good beginner courses on the internet? > > 73 > > Neal Campbell > Abroham Neal LLC > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Sat Aug 23 12:46:38 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sat, 23 Aug 2014 13:46:38 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> Message-ID: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> Hi Steve, RR, understood. I appreciate your point. But as you noted, the landscape has changed and is continually changing such that the world of FPGA programming is not limited to those senior FPGA programmers anymore. Granted, who knows if or how long FPGAs will be important, but for our project right now and for the forseeable future they are central to our designs. Therefore, it should be understood by all that the domain of FPGA programming is certainly not now limited to ?senior FPGA programmers?. We can successfully do such programming ourselves if we want to do it. 73, Joe K5SO On Aug 23, 2014, at 1:10 PM, Steven B. Dick wrote: > Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with > a desire to learn and my hat is off to you for taking it upon yourself to > learn both firmware and software programming. That was not the point I was > trying to make. In my previous life, I was a digital design manager. FPGA > code designed by experienced senior FPGA designers took a lot more time to > develop (even worse to maintain) compared to software written by experienced > software developers which ran on general purpose compute nodes. For many > years, FPGA designs had an important role to play where special functions > just could not be done in general purpose processors or even DSP processors > with comparable performance, but one willingly paid for it in reaping the > benefits of high performance and/or greatly reduced hardware footprint. But > the processing landscape is changing nowadays with very low cost processing > platforms based on multiple node graphics engines coupled with high order > language support with DSP libraries. Use of these platforms is starting to > result in huge performance capabilities in a low cost rapid development > environment if these platforms can be readily used for particular > applications including the FFT function. > > Regards, > "Digital Steve", K1RF > > -----Original Message----- > From: Joe Martin K5SO [mailto:k5so at valornet.com] > Sent: Saturday, August 23, 2014 2:06 PM > To: Rob Crewson > Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > A personal comment regarding FPGA programming and programming in general: > > The view that writing and maintaining FPGA code is beyond the capability of > most of us has been blown completely out of proportion to reality! That > view is simply incorrect. > > Indeed, I'm a good example of the point, I think. > 1408823198.0 From n9vv at wowway.com Sat Aug 23 16:13:32 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Sat, 23 Aug 2014 18:13:32 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> <36363AB0376D4B5C9E6C98648A03E7DC@Downstairs> <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> Message-ID: <53F9201C.8050306@wowway.com> P.S. I think Joe has a 4 digit IQ and he is just too polite to tell us!! 73 de Ken N9VV On 8/23/2014 2:46 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Steve, > > RR, understood. I appreciate your point. > > But as you noted, the landscape has changed and is continually changing such that the world of FPGA programming is not limited to those senior FPGA programmers anymore. Granted, who knows if or how long FPGAs will be important, but for our project right now and for the forseeable future they are central to our designs. Therefore, it should be understood by all that the domain of FPGA programming is certainly not now limited to ?senior FPGA programmers?. We can successfully do such programming ourselves if we want to do it. > > 73, Joe K5SO > > On Aug 23, 2014, at 1:10 PM, Steven B. Dick wrote: > >> Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with >> a desire to learn and my hat is off to you for taking it upon yourself to >> learn both firmware and software programming. That was not the point I was >> trying to make. In my previous life, I was a digital design manager. FPGA >> code designed by experienced senior FPGA designers took a lot more time to >> develop (even worse to maintain) compared to software written by experienced >> software developers which ran on general purpose compute nodes. For many >> years, FPGA designs had an important role to play where special functions >> just could not be done in general purpose processors or even DSP processors >> with comparable performance, but one willingly paid for it in reaping the >> benefits of high performance and/or greatly reduced hardware footprint. But >> the processing landscape is changing nowadays with very low cost processing >> platforms based on multiple node graphics engines coupled with high order >> language support with DSP libraries. Use of these platforms is starting to >> result in huge performance capabilities in a low cost rapid development >> environment if these platforms can be readily used for particular >> applications including the FFT function. >> >> Regards, >> "Digital Steve", K1RF >> >> -----Original Message----- >> From: Joe Martin K5SO [mailto:k5so at valornet.com] >> Sent: Saturday, August 23, 2014 2:06 PM >> To: Rob Crewson >> Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org >> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >> >> A personal comment regarding FPGA programming and programming in general: >> >> The view that writing and maintaining FPGA code is beyond the capability of >> most of us has been blown completely out of proportion to reality! That >> view is simply incorrect. >> >> Indeed, I'm a good example of the point, I think. >> > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1408835612.0 From w4yn at earthlink.net Sat Aug 23 16:18:39 2014 From: w4yn at earthlink.net (Tim ORourke) Date: Sat, 23 Aug 2014 19:18:39 -0400 (GMT-04:00) Subject: [hpsdr] openHPSDR at the forefront of SDR development Message-ID: <11504088.1408835920124.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> I think all the guys doing this are 4 digit geeks! And that's a great attribute IMHO! Tim Tim O\Rourke W4YN at ARRL.Net Low Power Amateur Radio Rocks Member of Flying Pigs,ARCI,GQRP,RSGB,ARRL Life Member R/C Pilot (sort of) NRA Life Member NRA Certified Rifle, Pistol, Black Powder Instructor, Range Officer -----Original Message----- >From: "Ken N9VV (Win-7/64)" >Sent: Aug 23, 2014 7:13 PM >To: hpsdr at lists.openhpsdr.org >Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > >***** High Performance Software Defined Radio Discussion List ***** > >P.S. I think Joe has a 4 digit IQ and he is just too polite to tell us!! > >73 de Ken N9VV > >On 8/23/2014 2:46 PM, Joe Martin K5SO wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Steve, >> >> RR, understood. I appreciate your point. >> >> But as you noted, the landscape has changed and is continually changing such that the world of FPGA programming is not limited to those senior FPGA programmers anymore. Granted, who knows if or how long FPGAs will be important, but for our project right now and for the forseeable future they are central to our designs. Therefore, it should be understood by all that the domain of FPGA programming is certainly not now limited to ?senior FPGA programmers?. We can successfully do such programming ourselves if we want to do it. >> >> 73, Joe K5SO >> >> On Aug 23, 2014, at 1:10 PM, Steven B. Dick wrote: >> >>> Hi Joe. Certainly verilog or VHDL FPGA coding can be learned by anyone with >>> a desire to learn and my hat is off to you for taking it upon yourself to >>> learn both firmware and software programming. That was not the point I was >>> trying to make. In my previous life, I was a digital design manager. FPGA >>> code designed by experienced senior FPGA designers took a lot more time to >>> develop (even worse to maintain) compared to software written by experienced >>> software developers which ran on general purpose compute nodes. For many >>> years, FPGA designs had an important role to play where special functions >>> just could not be done in general purpose processors or even DSP processors >>> with comparable performance, but one willingly paid for it in reaping the >>> benefits of high performance and/or greatly reduced hardware footprint. But >>> the processing landscape is changing nowadays with very low cost processing >>> platforms based on multiple node graphics engines coupled with high order >>> language support with DSP libraries. Use of these platforms is starting to >>> result in huge performance capabilities in a low cost rapid development >>> environment if these platforms can be readily used for particular >>> applications including the FFT function. >>> >>> Regards, >>> "Digital Steve", K1RF >>> >>> -----Original Message----- >>> From: Joe Martin K5SO [mailto:k5so at valornet.com] >>> Sent: Saturday, August 23, 2014 2:06 PM >>> To: Rob Crewson >>> Cc: 'Steven B. Dick'; hpsdr at lists.openhpsdr.org >>> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >>> >>> A personal comment regarding FPGA programming and programming in general: >>> >>> The view that writing and maintaining FPGA code is beyond the capability of >>> most of us has been blown completely out of proportion to reality! That >>> view is simply incorrect. >>> >>> Indeed, I'm a good example of the point, I think. >>> >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >_______________________________________________ >HPSDR Discussion List >To post msg: hpsdr at openhpsdr.org >Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >HPSDR web page: http://openhpsdr.org >Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408835919.0 From scotty at tonks.com Sat Aug 23 16:43:31 2014 From: scotty at tonks.com (Scott Cowling) Date: Sat, 23 Aug 2014 16:43:31 -0700 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <260DD696-CE58-4F14-A24E-55B5FFCCDC3F@valornet.com> References: <000001cfbeef$060a4030$121ec090$@cinci.rr.com> <0976DD9D-4C83-46D1-83AC-3B30657593EA@valornet.com> <260DD696-CE58-4F14-A24E-55B5FFCCDC3F@valornet.com> Message-ID: <53F92723.8020105@tonks.com> I want to echo Joe's sentiments on FPGA development exactly. In many respects, getting started in FPGA programming is *easier* than jumping into C++ programming. When you download the tools, the environment is all set up for you. You do not need to try to figure out which toolset to use, where to get it, how to configure it, etc. There are many excellent references and tutorials available for learning Verilog. If you are already a hardware designer, it is even easier, since Verilog synthesis constructs generate hardware. You can start out with the simple constructs, then learn and use more "elegant" style as you go. The absolute best way to start is by reading, understanding and modifying existing code examples. The SDRstick BeRadio FPGA design is a good starting place. Look in svn.sdrstick.com under "sdrstick-release/beradio/beradio-firmware/source". This is a commented, stand-alone AM radio design in Verilog. You can even get hardware to run it on if you like, but it is not necessary; there is benefit to gain just by studying the sample code. There are small FPGA development kits for as little as $49 if you want to try your hand at writing a "Hello LED" program (the hardware equivalent of the beginning C programmer's "Hello World" program). The two main things to remember are: 1. don't be afraid to jump right in 2. take it slowly and *have fun* I have been programming FPGAs since the 1980s, and it is *still* fun! 73, Scotty WA2DFI On 2014-08-23 12:23, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > There are many such sources for information. To learn the basics of the > Verilog language, which is what we use to write the FPGA code designs, > Kirk Weedman KD7IRS some years ago kindly put together a beginners > course tailored to the HPSDR project. The course is available for > download on the HPSDR webpage below: > > http://verilog.openhpsdr.org > > However, in my experience the absolute best way to learn how to do this > is by downloading Quartus II, installing it on your computer, and using > it to examine an existing HPSDR firmware design. By examing an actual > firmware design that we are using today you can see how the various > tasks are accomplished in the code. We try to comment the code as much > as is practical in order to help us remember what each section does but > also to help newcomers understand what the code section is doing. > > You can spend lots of unnecessary time attending/viewing classes which > will be giving you much info regarding Verilog syntax, etc, but you can > also get the idea very quickly by examining an actual firmware design by > using the Quartus II editor. In addition, you?ll immediately be > learning how to use the Quartus II tool. In short, my view that the > absolute best way to learn is to get your feet wet immediately with the > tool that you will be using; i.e., Quartus II, to examine an existing > firmware design. > > The primary issue to understand about FPGA code, in my view, is to > realize from the start that each little section of code within the > firmware design runs in parallel with every other section. That is, the > code execution is not ?event driven? as it is in Windows programming nor > is it strictly running lines of code sequentially as in some languages > (except within each section of code in the firmare design). Because of > this it is actually easy to take one little section of code and examine > it carefully to see what it is doing, how it is doing it, and what > syntax is used to accomplish it. > > After you feel you understand a portion of it then you can make small > changes to it, compile it, and see what effect your change(s) have on > the performance of the firmware design by actually loading it into your > HPSDR rigs? FPGA. Plus you immediately gain experience in how to do all > that. Sure, you?ll make mistakes! But be assured that anything you do > is recoverable; you can?t hurt the FPGA by misprogramming it. > > 73, Joe K5SO > > On Aug 23, 2014, at 12:46 PM, Neal Campbell wrote: > >> Are there any good beginner courses on the internet? >> >> 73 >> >> Neal Campbell >> Abroham Neal LLC >> >> >> > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1408837411.0 From brian13434 at yahoo.co.uk Sun Aug 24 05:38:15 2014 From: brian13434 at yahoo.co.uk (Brian D) Date: Sun, 24 Aug 2014 13:38:15 +0100 Subject: [hpsdr] Angelia_v4.2 firmware release In-Reply-To: References: Message-ID: Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > Angelia_v4.2 firmware is available for download from > > http://k5so.com/HPSDR_downloads.html > Is this suitable for use in the ANAN range of tranceivers or does it need to be changed by Abhi for the different filter frequencies? -- Brian D G3VGZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1408883895.0 From k5so at valornet.com Sun Aug 24 06:30:01 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 24 Aug 2014 07:30:01 -0600 Subject: [hpsdr] Angelia_v4.2 firmware release In-Reply-To: References: Message-ID: Hi Brian, The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. The firmware uses correct switch-point frequencies for the Alex filter set, which is also the correct switch-point frequencies for the ANAN-series radios that have the correct windings on their filters. It is my understanding that later versions of the ANAN series radios use correct windings on their 10/12m filters so their switch points should be identical to those in Alex. Earlier versions of the ANAN series radios do not. The firmware ?patch? used initially by Abhi to correct the 10m low power output for some ANAN series radios is not the ideal method for correcting the issue of low power output on 10m on those earlier ANAN radios, as the issue is actually a hardware issue, not a firmware or software issue. If Abhi wishes to create a version of firmware that uses different switch points from Alex that?s his prerogative but you should be aware that the issue is not actually a firmware issue, it?s a hardware issue. The fact is that there should be only a single firmware version to use with each of the Hermes, Angelia, and Orion boards, respectively, regardless of whether the board are used in an ANAN-series configuration with the Apache Labs filters or in a stand alone configuration using Alex filters. The "correct fix? for ANAN radios that have the low power output issue on 10m is to rewind the filter toroids for the 10/12 m filters on those radios, not to patch the firmware or software to use switch points that are different from the Alex filter design. 73, Joe K5SO On Aug 24, 2014, at 6:38 AM, Brian D wrote: > Joe Martin K5SO wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> All, >> >> Angelia_v4.2 firmware is available for download from >> >> http://k5so.com/HPSDR_downloads.html >> > Is this suitable for use in the ANAN range of tranceivers or does it need to > be changed by Abhi for the different filter frequencies? > > -- > Brian D > G3VGZ > > --- > This email is free from viruses and malware because avast! Antivirus protection is active. > http://www.avast.com > 1408887001.0 From k5so at valornet.com Sun Aug 24 06:43:04 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 24 Aug 2014 07:43:04 -0600 Subject: [hpsdr] Angelia_v4.2 firmware release In-Reply-To: References: Message-ID: > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. Excuse me. A more accurate statement would?ve been: "The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience a lower maximum output power on 10m than you will if the windings are correct.? 73, Joe K5SO On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Brian, > > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. > > The firmware uses correct switch-point frequencies for the Alex filter set, which is also the correct switch-point frequencies for the ANAN-series radios that have the correct windings on their filters. It is my understanding that later versions of the ANAN series radios use correct windings on their 10/12m filters so their switch points should be identical to those in Alex. Earlier versions of the ANAN series radios do not. > > The firmware ?patch? used initially by Abhi to correct the 10m low power output for some ANAN series radios is not the ideal method for correcting the issue of low power output on 10m on those earlier ANAN radios, as the issue is actually a hardware issue, not a firmware or software issue. If Abhi wishes to create a version of firmware that uses different switch points from Alex that?s his prerogative but you should be aware that the issue is not actually a firmware issue, it?s a hardware issue. > > The fact is that there should be only a single firmware version to use with each of the Hermes, Angelia, and Orion boards, respectively, regardless of whether the board are used in an ANAN-series configuration with the Apache Labs filters or in a stand alone configuration using Alex filters. The "correct fix? for ANAN radios that have the low power output issue on 10m is to rewind the filter toroids for the 10/12 m filters on those radios, not to patch the firmware or software to use switch points that are different from the Alex filter design. > > > 73, Joe K5SO > > On Aug 24, 2014, at 6:38 AM, Brian D wrote: > >> Joe Martin K5SO wrote: >> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> All, >>> >>> Angelia_v4.2 firmware is available for download from >>> >>> http://k5so.com/HPSDR_downloads.html >>> >> Is this suitable for use in the ANAN range of tranceivers or does it need to >> be changed by Abhi for the different filter frequencies? >> >> -- >> Brian D >> G3VGZ >> >> --- >> This email is free from viruses and malware because avast! Antivirus protection is active. >> http://www.avast.com >> > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408887784.0 From bjablonski at att.net Sun Aug 24 11:33:14 2014 From: bjablonski at att.net (Barry Jablonski) Date: Sun, 24 Aug 2014 14:33:14 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> Message-ID: <53FA2FEA.1080501@att.net> Hi Joe, I should know this, but -- where is the FPGA source code located? Barry WB2ZXJ 1408905194.0 From wb9qzb_groups at yahoo.com Sun Aug 24 11:34:29 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Sun, 24 Aug 2014 11:34:29 -0700 Subject: [hpsdr] Banquet Speaker & Sunday Seminar Annouced at ARRL/TAPR DCC (Digital Communications Conference), Austin, TX, 9/5 - 9/7 In-Reply-To: <1408905113.46795.YahooMailNeo@web140204.mail.bf1.yahoo.com> References: <53EDF934.8040708@sbcglobal.net> <1408905113.46795.YahooMailNeo@web140204.mail.bf1.yahoo.com> Message-ID: <1408905269.81493.YahooMailNeo@web140204.mail.bf1.yahoo.com> The 2014 ARRL/TAPR DCC?Saturday Night Banquet Speaker & Topic?will be? Gerald Youngblood, K5SDR presenting?"Accidental Company, the making of Flex Radio" ----- Forwarded Message ----- From: Stan Horzepa To: tapr-announce at tapr.org Sent: Friday, August 15, 2014 7:12 AM Subject: [tapr-announce] DCC in 3 weeks The 2014 ?ARRL/TAPR DCC will be on Friday, September 5th through Sunday, September 7th at the Austin Marriott South in Austin, Texas. The DCC has two days of technical forums on Friday and Saturday and a concurrent introductory forum on Saturday.? On Saturday night, the banquet will feature an interesting speaker andthe Sunday morning seminar will be "Introduction to SoC FPGA Programming for Mixed Signal Systems" by Chris Testa, KD2BMH. There will be free tables in the demo room to demonstrate projects and vendors to demonstrate products. Time is running out, so those interested in attending should register for the DCC and make hotel reservations ASAP. More DCC information is available at:?www.tapr.org/dcc? ? _______________________________________________ tapr-announce mailing list -------------- next part -------------- An HTML attachment was scrubbed... URL: From pa5bw at xs4all.nl Sun Aug 24 11:55:16 2014 From: pa5bw at xs4all.nl (Ben Witvliet) Date: Sun, 24 Aug 2014 20:55:16 +0200 Subject: [hpsdr] QSK question Message-ID: <81f5d1436d8c0bb8218afb700688ca0a.squirrel@webmail.xs4all.nl> Dear all, I hesistating to switch from my FT990 to an ANAN-200D as my primary RIG as I love the superb quality of the HPSDR receiver and I got hooked on the overview that the waterfall display offer. But I'm also a fanatic DX-er and CW QSK adept, and therefore CAN't LIVE without QSK ;-) I had Erik PA3DES demonstrate the ANAN-10D (HPSDR Hermes) to me with QSK on, but we could not get it working properly. Of course with paddle and headphones connected directly to the ANAN hardware. The switching seems fast enough, but after every dash or dit the AGC of the receiver has to slowly come back to normal, making it impossible to hear anything in between the CW symbols. (1) Any experienced HPSDR user and CW-er here that can tell me what settings we have wrong? (2) Any HPSDR user in The Netherlands that has experience with HF DX-ing in CW and with QSK willing to give a demo of his HPSDR station? Kindest regards, 73, Ben PE5B / PA5BW / 5R8DS 1408906516.0 From k5so at valornet.com Sun Aug 24 13:07:25 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 24 Aug 2014 14:07:25 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53FA2FEA.1080501@att.net> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> <53FA2FEA.1080501@att.net> Message-ID: <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> Hi Barry, The source code for all of the OpenHPSDR boards is located on the SVN. For Hermes as an example, the source code can be found at http://svn.tapr.org/repos_sdr_hpsdr/trunk/Hermes/Source/Hermes_v2.9/Heremes_v2.9.qar Similarly for Metis, Ozy, Mercury, and Penelope. For Angelia and Orion the source code is available on both my website download page within the firmware download zipped folder http://k5so.com/HPSDR_downloads.html and the Apache Labs download page (sorry, I don?t have the URL for that handy). The source code is generally stored in the form of a *.qar file, which is the Quartus II archive file format. It can be opened and edited and re-compiled if you wish using Quartus II. 73, Joe K5SO On Aug 24, 2014, at 12:33 PM, Barry Jablonski wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Joe, > > I should know this, but -- where is the FPGA source code located? > > Barry > WB2ZXJ 1408910845.0 From bjablonski at att.net Sun Aug 24 13:20:31 2014 From: bjablonski at att.net (Barry Jablonski) Date: Sun, 24 Aug 2014 16:20:31 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> <53FA2FEA.1080501@att.net> <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> Message-ID: <53FA490F.9040102@att.net> Thank you very much Joe for the info. I guess that I will have to reinstall Tortoise SVN on the Win7/64 Pro machine. It was on the old XP/32 SP3 box, but I failed to bring it forward. Barry WB2ZXJ On 8/24/2014 4:07 PM, Joe Martin K5SO wrote: > Hi Barry, > > The source code for all of the OpenHPSDR boards is located on the SVN. For Hermes as an example, the source code can be found at > > http://svn.tapr.org/repos_sdr_hpsdr/trunk/Hermes/Source/Hermes_v2.9/Heremes_v2.9.qar > > Similarly for Metis, Ozy, Mercury, and Penelope. > > For Angelia and Orion the source code is available on both my website download page within the firmware download zipped folder > > http://k5so.com/HPSDR_downloads.html > > and the Apache Labs download page (sorry, I don?t have the URL for that handy). > > The source code is generally stored in the form of a *.qar file, which is the Quartus II archive file format. It can be opened and edited and re-compiled if you wish using Quartus II. > > 73, Joe K5SO > > On Aug 24, 2014, at 12:33 PM, Barry Jablonski wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Joe, >> >> I should know this, but -- where is the FPGA source code located? >> >> Barry >> WB2ZXJ > 1408911631.0 From lstoskopf at cox.net Sun Aug 24 15:52:53 2014 From: lstoskopf at cox.net (lstoskopf at cox.net) Date: Sun, 24 Aug 2014 18:52:53 -0400 Subject: [hpsdr] Buy Jetson board? Message-ID: <20140824185253.KI4BB.171489.imail@eastrmwml114> Scotty has the new processor board coming out for his boards and I'm on board (!) when they are out. Ending up here with a pile of development boards (I don't mind). Is there enough SDR coming out/planned to buy a Jetson board and be a passive user or wait for the bigger version or ????????? Fun to try to keep up with the bleeding edge. N0UU 1408920773.0 From kv0s.dave at gmail.com Sun Aug 24 16:48:36 2014 From: kv0s.dave at gmail.com (Dave Larsen) Date: Sun, 24 Aug 2014 18:48:36 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53FA490F.9040102@att.net> References: <48BB0F12-E1BA-4179-BEB0-DD5AB677469E@valornet.com> <53FA2FEA.1080501@att.net> <080F95C8-65B2-4CDB-95E2-184D2795223A@valornet.com> <53FA490F.9040102@att.net> Message-ID: Barry - Just to let you and others know SVN Software works but you can download files one at time from the web interface and since all tha verlog file are in a *.qar file it may be easier to just use the web interface svn.tapr.org Dave KV0S On Aug 24, 2014 3:20 PM, "Barry Jablonski" wrote: > Thank you very much Joe for the info. > > I guess that I will have to reinstall Tortoise SVN on the Win7/64 Pro > machine. It was on the old XP/32 SP3 box, but I failed to bring it forward. > > Barry > WB2ZXJ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gokoyev+k3it at gmail.com Mon Aug 25 08:43:55 2014 From: gokoyev+k3it at gmail.com (k3it) Date: Mon, 25 Aug 2014 11:43:55 -0400 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) Message-ID: Is there an easy way to identify which radios need a correction for 10/12m coils? Vasiliy On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > The short answer is yes, but if you happen to have an ANAN-series radio > that has incorrect number of windings on the 10/12m filter toroids you will > experience low output power on 10m. > > > Excuse me. A more accurate statement would?ve been: > > "The short answer is yes, but if you happen to have an ANAN-series radio > that has incorrect number of windings on the 10/12m filter toroids you will > experience a lower maximum output power on 10m than you will if the > windings are correct.? > > 73, Joe K5SO > > > On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: > > > ***** High Performance Software Defined Radio Discussion List ***** > > > > Hi Brian, > > > > The short answer is yes, but if you happen to have an ANAN-series radio > that has incorrect number of windings on the 10/12m filter toroids you will > experience low output power on 10m. > > > > The firmware uses correct switch-point frequencies for the Alex filter > set, which is also the correct switch-point frequencies for the ANAN-series > radios that have the correct windings on their filters. It is my > understanding that later versions of the ANAN series radios use correct > windings on their 10/12m filters so their switch points should be identical > to those in Alex. Earlier versions of the ANAN series radios do not. > > > > The firmware ?patch? used initially by Abhi to correct the 10m low power > output for some ANAN series radios is not the ideal method for correcting > the issue of low power output on 10m on those earlier ANAN radios, as the > issue is actually a hardware issue, not a firmware or software issue. If > Abhi wishes to create a version of firmware that uses different switch > points from Alex that?s his prerogative but you should be aware that the > issue is not actually a firmware issue, it?s a hardware issue. > > > > The fact is that there should be only a single firmware version to use > with each of the Hermes, Angelia, and Orion boards, respectively, > regardless of whether the board are used in an ANAN-series configuration > with the Apache Labs filters or in a stand alone configuration using Alex > filters. The "correct fix? for ANAN radios that have the low power output > issue on 10m is to rewind the filter toroids for the 10/12 m filters on > those radios, not to patch the firmware or software to use switch points > that are different from the Alex filter design. > > > > > > 73, Joe K5SO > > > > On Aug 24, 2014, at 6:38 AM, Brian D wrote: > > > >> Joe Martin K5SO wrote: > >> > >>> ***** High Performance Software Defined Radio Discussion List ***** > >>> > >>> All, > >>> > >>> Angelia_v4.2 firmware is available for download from > >>> > >>> http://k5so.com/HPSDR_downloads.html > >>> > >> Is this suitable for use in the ANAN range of tranceivers or does it > need to > >> be changed by Abhi for the different filter frequencies? > >> > >> -- > >> Brian D > >> G3VGZ > >> > >> --- > >> This email is free from viruses and malware because avast! Antivirus > protection is active. > >> http://www.avast.com > >> > > > > _______________________________________________ > > HPSDR Discussion List > > To post msg: hpsdr at openhpsdr.org > > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > > HPSDR web page: http://openhpsdr.org > > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 25 09:25:10 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 25 Aug 2014 10:25:10 -0600 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: It is my understanding that L15 should have 8 turns and L16 should have 9 turns, both of 22 AWG wire. If they do not, then you may observe a lower output power on 10m Tx than you would otherwise. 73, Joe K5SO On Aug 25, 2014, at 9:43 AM, k3it wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Is there an easy way to identify which radios need a correction for 10/12m coils? > > Vasiliy > > > On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. > > > Excuse me. A more accurate statement would?ve been: > > "The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience a lower maximum output power on 10m than you will if the windings are correct.? > > 73, Joe K5SO > > > On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: > > > ***** High Performance Software Defined Radio Discussion List ***** > > > > Hi Brian, > > > > The short answer is yes, but if you happen to have an ANAN-series radio that has incorrect number of windings on the 10/12m filter toroids you will experience low output power on 10m. > > > > The firmware uses correct switch-point frequencies for the Alex filter set, which is also the correct switch-point frequencies for the ANAN-series radios that have the correct windings on their filters. It is my understanding that later versions of the ANAN series radios use correct windings on their 10/12m filters so their switch points should be identical to those in Alex. Earlier versions of the ANAN series radios do not. > > > > The firmware ?patch? used initially by Abhi to correct the 10m low power output for some ANAN series radios is not the ideal method for correcting the issue of low power output on 10m on those earlier ANAN radios, as the issue is actually a hardware issue, not a firmware or software issue. If Abhi wishes to create a version of firmware that uses different switch points from Alex that?s his prerogative but you should be aware that the issue is not actually a firmware issue, it?s a hardware issue. > > > > The fact is that there should be only a single firmware version to use with each of the Hermes, Angelia, and Orion boards, respectively, regardless of whether the board are used in an ANAN-series configuration with the Apache Labs filters or in a stand alone configuration using Alex filters. The "correct fix? for ANAN radios that have the low power output issue on 10m is to rewind the filter toroids for the 10/12 m filters on those radios, not to patch the firmware or software to use switch points that are different from the Alex filter design. > > > > > > 73, Joe K5SO > > > > On Aug 24, 2014, at 6:38 AM, Brian D wrote: > > > >> Joe Martin K5SO wrote: > >> > >>> ***** High Performance Software Defined Radio Discussion List ***** > >>> > >>> All, > >>> > >>> Angelia_v4.2 firmware is available for download from > >>> > >>> http://k5so.com/HPSDR_downloads.html > >>> > >> Is this suitable for use in the ANAN range of tranceivers or does it need to > >> be changed by Abhi for the different filter frequencies? > >> > >> -- > >> Brian D > >> G3VGZ > >> > >> --- > >> This email is free from viruses and malware because avast! Antivirus protection is active. > >> http://www.avast.com > >> > > > > _______________________________________________ > > HPSDR Discussion List > > To post msg: hpsdr at openhpsdr.org > > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > > HPSDR web page: http://openhpsdr.org > > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Mon Aug 25 09:36:31 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Mon, 25 Aug 2014 10:36:31 -0600 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: <2E9C3C33-83C3-4A84-A93C-24EEBD89753C@valornet.com> References: <2E9C3C33-83C3-4A84-A93C-24EEBD89753C@valornet.com> Message-ID: It is my further understanding that radios that have the 100W PA and were shipped after March 2014 have the correct number of windings on the 10/12m LPF toroids. 73, Joe K5SO On Aug 25, 2014, at 10:25 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > It is my understanding that L15 should have 8 turns and L16 should have 9 turns, both of 22 AWG wire. > > If they do not, then you may observe a lower output power on 10m Tx than you would otherwise. > > 73, Joe K5SO > > > On Aug 25, 2014, at 9:43 AM, k3it wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Is there an easy way to identify which radios need a correction for 10/12m coils? >> >> Vasiliy > 1408984591.0 From abhiarunoday at gmail.com Mon Aug 25 09:53:03 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Mon, 25 Aug 2014 22:23:03 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: Hi Vasiliy, The Original Angelia/Orion firmware extends the 17/15M LPF upto 27Mhz so that 12M is incorporated within this LPF, the Hermes firmware is modified to the (B) version by me to enable this, Firmware that you download from the Apache website incorporates this change, 73s, Abhi On Mon, Aug 25, 2014 at 9:13 PM, k3it wrote: > Is there an easy way to identify which radios need a correction for 10/12m > coils? > > Vasiliy > > > On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO > wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> >> >> Excuse me. A more accurate statement would?ve been: >> >> "The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience a lower maximum output power on 10m than you will if the >> windings are correct.? >> >> 73, Joe K5SO >> >> >> On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: >> >> > ***** High Performance Software Defined Radio Discussion List ***** >> > >> > Hi Brian, >> > >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> > >> > The firmware uses correct switch-point frequencies for the Alex filter >> set, which is also the correct switch-point frequencies for the ANAN-series >> radios that have the correct windings on their filters. It is my >> understanding that later versions of the ANAN series radios use correct >> windings on their 10/12m filters so their switch points should be identical >> to those in Alex. Earlier versions of the ANAN series radios do not. >> > >> > The firmware ?patch? used initially by Abhi to correct the 10m low >> power output for some ANAN series radios is not the ideal method for >> correcting the issue of low power output on 10m on those earlier ANAN >> radios, as the issue is actually a hardware issue, not a firmware or >> software issue. If Abhi wishes to create a version of firmware that uses >> different switch points from Alex that?s his prerogative but you should be >> aware that the issue is not actually a firmware issue, it?s a hardware >> issue. >> > >> > The fact is that there should be only a single firmware version to use >> with each of the Hermes, Angelia, and Orion boards, respectively, >> regardless of whether the board are used in an ANAN-series configuration >> with the Apache Labs filters or in a stand alone configuration using Alex >> filters. The "correct fix? for ANAN radios that have the low power output >> issue on 10m is to rewind the filter toroids for the 10/12 m filters on >> those radios, not to patch the firmware or software to use switch points >> that are different from the Alex filter design. >> > >> > >> > 73, Joe K5SO >> > >> > On Aug 24, 2014, at 6:38 AM, Brian D wrote: >> > >> >> Joe Martin K5SO wrote: >> >> >> >>> ***** High Performance Software Defined Radio Discussion List ***** >> >>> >> >>> All, >> >>> >> >>> Angelia_v4.2 firmware is available for download from >> >>> >> >>> http://k5so.com/HPSDR_downloads.html >> >>> >> >> Is this suitable for use in the ANAN range of tranceivers or does it >> need to >> >> be changed by Abhi for the different filter frequencies? >> >> >> >> -- >> >> Brian D >> >> G3VGZ >> >> >> >> --- >> >> This email is free from viruses and malware because avast! Antivirus >> protection is active. >> >> http://www.avast.com >> >> >> > >> > _______________________________________________ >> > HPSDR Discussion List >> > To post msg: hpsdr at openhpsdr.org >> > Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> > HPSDR web page: http://openhpsdr.org >> > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhiarunoday at gmail.com Mon Aug 25 10:22:48 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Mon, 25 Aug 2014 22:52:48 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this, 73s, Abhi On Monday, August 25, 2014, k3it wrote: > Is there an easy way to identify which radios need a correction for 10/12m > coils? > > Vasiliy > > > On Sun, Aug 24, 2014 at 9:43 AM, Joe Martin K5SO > wrote: > >> ***** High Performance Software Defined Radio Discussion List ***** >> >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> >> >> Excuse me. A more accurate statement would?ve been: >> >> "The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience a lower maximum output power on 10m than you will if the >> windings are correct.? >> >> 73, Joe K5SO >> >> >> On Aug 24, 2014, at 7:30 AM, Joe Martin K5SO wrote: >> >> > ***** High Performance Software Defined Radio Discussion List ***** >> > >> > Hi Brian, >> > >> > The short answer is yes, but if you happen to have an ANAN-series radio >> that has incorrect number of windings on the 10/12m filter toroids you will >> experience low output power on 10m. >> > >> > The firmware uses correct switch-point frequencies for the Alex filter >> set, which is also the correct switch-point frequencies for the ANAN-series >> radios that have the correct windings on their filters. It is my >> understanding that later versions of the ANAN series radios use correct >> windings on their 10/12m filters so their switch points should be identical >> to those in Alex. Earlier versions of the ANAN series radios do not. >> > >> > The firmware ?patch? used initially by Abhi to correct the 10m low >> power output for some ANAN series radios is not the ideal method for >> correcting the issue of low power output on 10m on those earlier ANAN >> radios, as the issue is actually a hardware issue, not a firmware or >> software issue. If Abhi wishes to create a version of firmware that uses >> different switch points from Alex that?s his prerogative but you should be >> aware that the issue is not actually a firmware issue, it?s a hardware >> issue. >> > >> > The fact is that there should be only a single firmware version to use >> with each of the Hermes, Angelia, and Orion boards, respectively, >> regardless of whether the board are used in an ANAN-series configuration >> with the Apache Labs filters or in a stand alone configuration using Alex >> filters. The "correct fix? for ANAN radios that have the low power output >> issue on 10m is to rewind the filter toroids for the 10/12 m filters on >> those radios, not to patch the firmware or software to use switch points >> that are different from the Alex filter design. >> > >> > >> > 73, Joe K5SO >> > >> > On Aug 24, 2014, at 6:38 AM, Brian D wrote: >> > >> >> Joe Martin K5SO > > wrote: >> >> >> >>> ***** High Performance Software Defined Radio Discussion List ***** >> >>> >> >>> All, >> >>> >> >>> Angelia_v4.2 firmware is available for download from >> >>> >> >>> http://k5so.com/HPSDR_downloads.html >> >>> >> >> Is this suitable for use in the ANAN range of tranceivers or does it >> need to >> >> be changed by Abhi for the different filter frequencies? >> >> >> >> -- >> >> Brian D >> >> G3VGZ >> >> >> >> --- >> >> This email is free from viruses and malware because avast! Antivirus >> protection is active. >> >> http://www.avast.com >> >> >> > >> > _______________________________________________ >> > HPSDR Discussion List >> > To post msg: hpsdr at openhpsdr.org >> >> > Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> > HPSDR web page: http://openhpsdr.org >> > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> _______________________________________________ >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> >> Subscription help: >> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjablonski at att.net Mon Aug 25 10:31:25 2014 From: bjablonski at att.net (Barry Jablonski) Date: Mon, 25 Aug 2014 13:31:25 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: <53FB72ED.8060107@att.net> Thanks for that information Dave. I'm mainly interested in the Hermes FPGA code and this will save me time. I also just found out I will have to downgrade Quartus II from v14 to v13.1 since the latest version has dropped support for Cyclone III devices. Barry WB2ZXJ 1408987885.0 From mstangelo at comcast.net Mon Aug 25 12:49:23 2014 From: mstangelo at comcast.net (mstangelo at comcast.net) Date: Mon, 25 Aug 2014 19:49:23 +0000 (UTC) Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: References: Message-ID: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> Abhi, You responded with: "Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this," You also had an issue low power with 12M. Do we need your special code to switcg in different LP filters for the 12 Meter band? Mike N2MS ----- Original Message ----- From: Abhi A To: k3it Cc: HPSDR list Sent: Mon, 25 Aug 2014 17:22:48 -0000 (UTC) Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** 1408996163.0 From gregg.w6izt1 at gmail.com Mon Aug 25 12:55:49 2014 From: gregg.w6izt1 at gmail.com (Gregg W6IZT) Date: Mon, 25 Aug 2014 15:55:49 -0400 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> References: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> Message-ID: <047601cfc09e$91ea2240$b5be66c0$@gmail.com> I had the low power issue on 12 m and a change to the FW resolved it. I'd prefer to address a HW problem in HW by adjusting the inductors in the LPF to have the correct number of turns. I now have that information on the correct number of turns for the inductors in question. Question: Will I need to change the FW if I correct the inductors? Gregg W6IZT -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of mstangelo at comcast.net Sent: Monday, August 25, 2014 3:49 PM To: Abhi A Cc: HPSDR list Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** Abhi, You responded with: "Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this," You also had an issue low power with 12M. Do we need your special code to switcg in different LP filters for the 12 Meter band? Mike N2MS ----- Original Message ----- From: Abhi A To: k3it Cc: HPSDR list Sent: Mon, 25 Aug 2014 17:22:48 -0000 (UTC) Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408996549.0 From ka6tya at arrl.net Mon Aug 25 13:22:35 2014 From: ka6tya at arrl.net (Pat McGrath) Date: Mon, 25 Aug 2014 13:22:35 -0700 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) In-Reply-To: <047601cfc09e$91ea2240$b5be66c0$@gmail.com> References: <123894719.10512451.1408996163762.JavaMail.root@comcast.net> <047601cfc09e$91ea2240$b5be66c0$@gmail.com> Message-ID: <000301cfc0a2$4ed683f0$ec838bd0$@arrl.net> Abhi A Will your company permanently fix the problem? -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Gregg W6IZT Sent: Monday, August 25, 2014 12:56 PM To: mstangelo at comcast.net; 'Abhi A' Cc: 'HPSDR list' Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** I had the low power issue on 12 m and a change to the FW resolved it. I'd prefer to address a HW problem in HW by adjusting the inductors in the LPF to have the correct number of turns. I now have that information on the correct number of turns for the inductors in question. Question: Will I need to change the FW if I correct the inductors? Gregg W6IZT -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of mstangelo at comcast.net Sent: Monday, August 25, 2014 3:49 PM To: Abhi A Cc: HPSDR list Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** Abhi, You responded with: "Oops I might as well be on a different planet :), sorry my previous post was not relevant to your query,, If you are getting 100Ws on 10M you are OK, the 10M low power did not effect all radios some radios had low output on 10M this was due to the variance in board capacitance from lot to lot which is quite typical in FR4 material, however, we did make a change to the 10M LPF coils in order to prevent this," You also had an issue low power with 12M. Do we need your special code to switcg in different LP filters for the 12 Meter band? Mike N2MS ----- Original Message ----- From: Abhi A To: k3it Cc: HPSDR list Sent: Mon, 25 Aug 2014 17:22:48 -0000 (UTC) Subject: Re: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) ***** High Performance Software Defined Radio Discussion List ***** _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1408998155.0 From abhiarunoday at gmail.com Mon Aug 25 20:46:58 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Tue, 26 Aug 2014 09:16:58 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) Message-ID: Hi Guys, I think there is some confusion here, all ANAN radios use the 17/15M LPF on 12M as well, changing the coils on the 10M LPF does not effect the 12M output, The change in the 10M LPF was to prevent low output on the 10M band in some radios, if you are not experiencing low power on 10M this does not effect you, The Orion and Angelia firmware already have this change coded in, the Original Hermes firmware does not, hence, Apache releases a B version which incorporates this change, 73s, Abhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Mon Aug 25 21:53:53 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Mon, 25 Aug 2014 23:53:53 -0500 Subject: [hpsdr] Fwd: RE: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: Is it just me or does the fwd pwr TX meter seem to be to be reading lower than it should with this release? I was checking power outputs and it seems to be about 15 watts lower than reality. Is this just me? I was trying to adjust output power and that's when I realized it. I reset databases just to be sure. I didn't notice this on 3.2.17. 73, Jae - K5JAE -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhiarunoday at gmail.com Mon Aug 25 22:38:55 2014 From: abhiarunoday at gmail.com (Abhi A) Date: Tue, 26 Aug 2014 11:08:55 +0530 Subject: [hpsdr] 10/12m coil windings (Re: Angelia_v4.2 firmware release) Message-ID: Further update and correction: The 10M Coil update also fixes the 12M low power output, however, using the 17/15M LPF for 12M also works, The current Orion firmware uses the 10M LPF for 12M, all 200Ds shipped have the LPF change incorporated, The Angelia and Hermes (B) Firmware uses the 17/15M LPF for 12M, I believe all radios shipped from March 2014 as Joe indicated have this change incorporated, In case you are experiencing low output on 12/10M please contact Apache Support and we will be happy to assist in resolving this issue, 73s, Abhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian13434 at yahoo.co.uk Tue Aug 26 02:54:53 2014 From: brian13434 at yahoo.co.uk (Brian D) Date: Tue, 26 Aug 2014 10:54:53 +0100 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: Jae Stutzman wrote: > Is it just me or does the fwd pwr TX meter seem to be to be reading lower > than it should with this release? I was checking power outputs and it > seems to be about 15 watts lower than reality. Is this just me? I was > trying to adjust output power and that's when I realized it. I reset > databases just to be sure. I didn't notice this on 3.2.17. I haven't noticed it reading low but I've had several times it reading NaN for VSWR when tuning into the goood match of my test load. Not sure at this stage if it is the new version of HPSDR or my recent firmware upgrade to 4.2 (angelia). -- Brian D G3VGZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1409046893.0 From k5jae at stutzman.net Tue Aug 26 05:38:52 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Tue, 26 Aug 2014 07:38:52 -0500 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: I should have mentioned that I recently upgraded to 4.2 Angelia as well. So it could be either. I'll try downgrading back to 4.1 to see if that changes anything. I noticed it with TUN and it was reading out about 85W for each band. I was originally trying to find out if I was affected by the 10M winding issue. On Tue, Aug 26, 2014 at 4:54 AM, Brian D wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Jae Stutzman wrote: > > > Is it just me or does the fwd pwr TX meter seem to be to be reading lower > > than it should with this release? I was checking power outputs and it > > seems to be about 15 watts lower than reality. Is this just me? I was > > trying to adjust output power and that's when I realized it. I reset > > databases just to be sure. I didn't notice this on 3.2.17. > > I haven't noticed it reading low but I've had several times it reading NaN > for VSWR when tuning into the goood match of my test load. Not sure at this > stage if it is the new version of HPSDR or my recent firmware upgrade to > 4.2 > (angelia). > > > -- > Brian D > G3VGZ > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernd.gasser at tele2.at Tue Aug 26 06:01:36 2014 From: bernd.gasser at tele2.at (Bernd Gasser) Date: Tue, 26 Aug 2014 15:01:36 +0200 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: References: <20140817163704.A6AAD48278@diego.dreamhost.com> Message-ID: <008001cfc12d$dea6b4b0$9bf41e10$@tele2.at> Hi Hermann et al, after seeing all your interesting messages I was also infected by the cuda-virus and ordered a Jetson TK1 to play with. So far I managed to set it up with Qt5.4 and cuda-6.0 installed and I have successfully compiled cuSDR64 and ghpsdr-alex on it which both seems to run fine with a little high CPU-load. (cuSDR64 shows abt 155%). When looking at the shared libraries mapped to the running binary I noticed it is still using the 'standard libfftw3' library instead of the ones optimized for the TEGRA 192 GPU cores supplied with cuda-6.0. UID PID PPID C STIME TTY TIME CMD ubuntu 2942 2607 99 12:07 pts/4 00:38:25 ./cuSDR64 ubuntu at tegra-ubuntu:/proc/2942$ grep fftw maps b6665000-b67ad000 r-xp 00000000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 b67ad000-b67b4000 ---p 00148000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 b67b4000-b67bc000 r--p 00147000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 b67bc000-b67bd000 rw-p 0014f000 b3:01 23545 /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 What would be the required change in the build environment to make use of the cuda-6.0 libraries in /usr/local/cuda-6.0/lib/libcufftw* ? - Has anyone done this yet and could give me some pointers? tnx & 73, Bernd/OE1ACM -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von Hermann Gesendet: Montag, 18. August 2014 13:24 An: Chris Smith; hpsdr at lists.openhpsdr.org Betreff: Re: [hpsdr] 20140126cuSDR64 & TK1 ***** High Performance Software Defined Radio Discussion List ***** 1409058096.0 From gokoyev+k3it at gmail.com Tue Aug 26 06:23:48 2014 From: gokoyev+k3it at gmail.com (k3it) Date: Tue, 26 Aug 2014 09:23:48 -0400 Subject: [hpsdr] 20140126cuSDR64 & TK1 In-Reply-To: <008001cfc12d$dea6b4b0$9bf41e10$@tele2.at> References: <20140817163704.A6AAD48278@diego.dreamhost.com> <008001cfc12d$dea6b4b0$9bf41e10$@tele2.at> Message-ID: Here is a link that describes what needs to be done to convert to cufftw http://docs.nvidia.com/cuda/cufft/index.html#fftw-supported-interface But this looks too easy to be true :) I haven't tried it. Also running Jetson board here with gphpsdr3 73 Vasiliy On Tue, Aug 26, 2014 at 9:01 AM, Bernd Gasser wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Hermann et al, > after seeing all your interesting messages I was also infected by the > cuda-virus and ordered a Jetson TK1 to play with. > > So far I managed to set it up with Qt5.4 and cuda-6.0 installed and I have > successfully compiled cuSDR64 and ghpsdr-alex on it which both seems to run > fine with a little high CPU-load. (cuSDR64 shows abt 155%). > > When looking at the shared libraries mapped to the running binary I noticed > it is still using the 'standard libfftw3' library instead of the ones > optimized for the TEGRA 192 GPU cores supplied with cuda-6.0. > > > UID PID PPID C STIME TTY TIME CMD > ubuntu 2942 2607 99 12:07 pts/4 00:38:25 ./cuSDR64 > > ubuntu at tegra-ubuntu:/proc/2942$ grep fftw maps > b6665000-b67ad000 r-xp 00000000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > b67ad000-b67b4000 ---p 00148000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > b67b4000-b67bc000 r--p 00147000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > b67bc000-b67bd000 rw-p 0014f000 b3:01 23545 > /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3.3.2 > > What would be the required change in the build environment to make use of > the cuda-6.0 libraries in /usr/local/cuda-6.0/lib/libcufftw* ? - Has > anyone > done this yet and could give me some pointers? > > tnx & 73, > Bernd/OE1ACM > > > > > > > > -----Urspr?ngliche Nachricht----- > Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von > Hermann > Gesendet: Montag, 18. August 2014 13:24 > An: Chris Smith; hpsdr at lists.openhpsdr.org > Betreff: Re: [hpsdr] 20140126cuSDR64 & TK1 > > ***** High Performance Software Defined Radio Discussion List ***** > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnlaur at gmail.com Tue Aug 26 08:08:04 2014 From: johnlaur at gmail.com (John Laur) Date: Tue, 26 Aug 2014 10:08:04 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: Ideas for discussion: First, isn't this similar to the architecture that has been implemented by PA3FWM's wideband websdr for some time? ADC->FPGA->Ethernet->FFT with GPU and then individual receivers only have to grab the bins and do an IFFT? If so, it's a clear winner as far as scaling the capabilities go. I am very excited to see the excitement for it. But I am concerned with the discussion dwelling around the Jetson board as being central and essential to this architecture long-term although I do think it is valuable as a motivator. For a hardware architecture that will hang around for a while and be the most compatible, I would like to discuss the option of designing instead for regular (non-mini) PCI-e. While it's great to have these 'fun-size' SBC's there is really nothing that I have seen to conclude that NVidia or a 3rd party will continue to ship such a thing as a developer or retail product with extremely similar architecture and form factor over the long term. So unless there is someone who wants to keep up with the hassle of actually integrating NVidia silicon onto an HPSDR board and making a wholly integrated system a la the Flex-6k, I do not think it is worth exploring too far into that paradigm. Designing for the Jetson's mini-pcie interface would severely limit future flexibility should the product be dropped and limit the use of the HPSDR hardware in cases where mini-pcie is not available on a board with a suitable CUDA GPU. Plus, Jetson itself has a huge disadvantage (for the HPSDR server application) of having only a single Ethernet interface. I understand that there is still 16Mbps of bandwidth 'left over' (and that the interface itself is full duplex) but that is an awfully limiting margin considering the possibilities that exist with the architecture. Yes; one could be added on USB without occupying the mini-PCIe, but at the expense of the limited CPU resources. Running ethernet interfaces at 99% capacity is a tricky business anyway. It would be nice to simply eliminate that challenge. There is one thing we can be sure of though: NVidia will continue to ship regular PCI-e graphics cards for the foreseeable future. Depending on the version of CUDA required, an inexpensive NVidia GeForce card will likely exceed Jetson's performance by quite a lot. A small dedicated system with dual PCIe slots and a GPU can be designed and built with specifications exceeding those of the Jetson board at similar cost, and the same architecture can be implemented. I do not see that the Jetson has any advantage over such system other than perhaps power consumption or having fixed design. The problem of power consumption is likely not to be a large concern in this application, and the second problem can be eliminated by specifying a tested reference design. * PCI-e is the fastest common interface available. Current standards take speeds to 250gbps (PCI-e 4.0 x16), and even the lowest common denominator (PCI-e 1.0 1x) is still 2gbps. * PCI-e can be bridged to Mini-PCIe, Thunderbolt, or Expresscard interfaces with off-the-shelf hardware. * PCI-e supports DMA, RDMA, and peer to peer data transfer. Data can be moved from HPDSR to GPU without involving the CPU. A passive PCI-e backplane could be used as a future replacement for Atlas with the ability to use off the shelf parts. * PCI-e is easy to interface in the modern Altera FPGAs with hardware controllers and does not require the difficult task of writing IP for 3rd party interface chips (Existing IP for things like USB 3.0 controllers and 10gbE chips are licensed and generally not compatible with open-source licenses. I believe this is one of the major pain points with the current HPSDR FPGA efforts.) * PCI-e is generally backwards (and forwards!) compatible. So modern high-bandwidth hardware can be designed and still used with older or less powerful hosts. An external interface of some sort has the advantage that the RF bits can be somewhat isolated from the noisy computer bits, but there are ways to mitigate that and still use PCI-e, such as using a case design that ensures the RF side is well shielded. The design could also be broken into two parts with the ADC/DAC/Clocks isolated and connected to the FPGA on a PCI-e card by means of line driver ICs and off-the-shelf cables. Any thoughts from those more involved with the software or hardware design? 73, John KF5SAB On Fri, Aug 22, 2014 at 10:31 PM, Phil Harman wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Marc, > > Thanks for your email. > > We still have a way to go with fully proving the DFC idea but so far its looking good. > > We actually had this discussion a few minutes ago during the weekly Teamspeak session. > > Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. > > What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. > > What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. > > With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. > > If such a PCB design is of interest to you then please lets discuss further. > > 73 Phil....VK6PH > > > -----Original Message----- From: Marc Lalonde > Sent: Saturday, August 23, 2014 10:31 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > guess some one already work on a ADC /DAC Board that go on the expansion > connector of the DEV kit ? > seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA > as Glue logic.. > > that may remove the LAN / PHY from equation and permit made nice self > contained platform ;-) > > if no one yet ,i may willing to help work on this ,i was a senior PCB > designer whit some design backgrond .. > > Best 73! > Marc VE2OLM 1409065684.0 From k5so at valornet.com Tue Aug 26 09:35:24 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Tue, 26 Aug 2014 10:35:24 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <3AD73732-607A-4AB5-96C3-5B78FB0B1477@valornet.com> Hi John, I completely agree with your analysis and have in fact privately expressed to several people my concern regarding use of a (marginally powerful) single board computer in the mix. But keep in mind that the new protocol that Phil is contemplating will work fine with either a single powerful computer (SBC) connected to the hardware OR with a high performance computer connected to the hardware as we have traditionally done. Therefore the SBC development activity underway doesn?t limit things at all for those of us who would prefer to use a single high performance computer instead. Users of a single high performance computer can still exploit the new protocol and realize the same flexibility and performance benefits that Phil mentioned that are associated with the new proposed ethernet protocol. The Jetson board SBC approach is simply an activity that is running in parallel with the original architecture scheme. Whether you wish to use an SBC configuration or not is entirely optional and open to your personal preference. I?ve come to realize that we?re not losing anything at all by having some people working on SBC configurations in order to have low-performance hand held devices able to interface the hardware (if that happens to be your personal interest). 73, Joe K5SO 1409070924.0 From dc6ny at gmx.de Tue Aug 26 09:36:24 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Tue, 26 Aug 2014 18:36:24 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <000001cfc14b$e0b5c2f0$a22148d0$@de> Nice reasoning, John. Thanks. 73, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von John Laur Gesendet: Dienstag, 26. August 2014 17:08 An: HPSDR list Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** Ideas for discussion: First, isn't this similar to the architecture that has been implemented by PA3FWM's wideband websdr for some time? ADC->FPGA->Ethernet->FFT with GPU and then individual receivers only have to grab the bins and do an IFFT? If so, it's a clear winner as far as scaling the capabilities go. I am very excited to see the excitement for it. But I am concerned with the discussion dwelling around the Jetson board as being central and essential to this architecture long-term although I do think it is valuable as a motivator. For a hardware architecture that will hang around for a while and be the most compatible, I would like to discuss the option of designing instead for regular (non-mini) PCI-e. While it's great to have these 'fun-size' SBC's there is really nothing that I have seen to conclude that NVidia or a 3rd party will continue to ship such a thing as a developer or retail product with extremely similar architecture and form factor over the long term. So unless there is someone who wants to keep up with the hassle of actually integrating NVidia silicon onto an HPSDR board and making a wholly integrated system a la the Flex-6k, I do not think it is worth exploring too far into that paradigm. Designing for the Jetson's mini-pcie interface would severely limit future flexibility should the product be dropped and limit the use of the HPSDR hardware in cases where mini-pcie is not available on a board with a suitable CUDA GPU. Plus, Jetson itself has a huge disadvantage (for the HPSDR server application) of having only a single Ethernet interface. I understand that there is still 16Mbps of bandwidth 'left over' (and that the interface itself is full duplex) but that is an awfully limiting margin considering the possibilities that exist with the architecture. Yes; one could be added on USB without occupying the mini-PCIe, but at the expense of the limited CPU resources. Running ethernet interfaces at 99% capacity is a tricky business anyway. It would be nice to simply eliminate that challenge. There is one thing we can be sure of though: NVidia will continue to ship regular PCI-e graphics cards for the foreseeable future. Depending on the version of CUDA required, an inexpensive NVidia GeForce card will likely exceed Jetson's performance by quite a lot. A small dedicated system with dual PCIe slots and a GPU can be designed and built with specifications exceeding those of the Jetson board at similar cost, and the same architecture can be implemented. I do not see that the Jetson has any advantage over such system other than perhaps power consumption or having fixed design. The problem of power consumption is likely not to be a large concern in this application, and the second problem can be eliminated by specifying a tested reference design. * PCI-e is the fastest common interface available. Current standards take speeds to 250gbps (PCI-e 4.0 x16), and even the lowest common denominator (PCI-e 1.0 1x) is still 2gbps. * PCI-e can be bridged to Mini-PCIe, Thunderbolt, or Expresscard interfaces with off-the-shelf hardware. * PCI-e supports DMA, RDMA, and peer to peer data transfer. Data can be moved from HPDSR to GPU without involving the CPU. A passive PCI-e backplane could be used as a future replacement for Atlas with the ability to use off the shelf parts. * PCI-e is easy to interface in the modern Altera FPGAs with hardware controllers and does not require the difficult task of writing IP for 3rd party interface chips (Existing IP for things like USB 3.0 controllers and 10gbE chips are licensed and generally not compatible with open-source licenses. I believe this is one of the major pain points with the current HPSDR FPGA efforts.) * PCI-e is generally backwards (and forwards!) compatible. So modern high-bandwidth hardware can be designed and still used with older or less powerful hosts. An external interface of some sort has the advantage that the RF bits can be somewhat isolated from the noisy computer bits, but there are ways to mitigate that and still use PCI-e, such as using a case design that ensures the RF side is well shielded. The design could also be broken into two parts with the ADC/DAC/Clocks isolated and connected to the FPGA on a PCI-e card by means of line driver ICs and off-the-shelf cables. Any thoughts from those more involved with the software or hardware design? 73, John KF5SAB On Fri, Aug 22, 2014 at 10:31 PM, Phil Harman wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi Marc, > > Thanks for your email. > > We still have a way to go with fully proving the DFC idea but so far its looking good. > > We actually had this discussion a few minutes ago during the weekly Teamspeak session. > > Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. > > What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. > > What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. > > With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. > > If such a PCB design is of interest to you then please lets discuss further. > > 73 Phil....VK6PH > > > -----Original Message----- From: Marc Lalonde > Sent: Saturday, August 23, 2014 10:31 AM > To: hpsdr at lists.openhpsdr.org > Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development > > > ***** High Performance Software Defined Radio Discussion List ***** > > Hi > > guess some one already work on a ADC /DAC Board that go on the > expansion connector of the DEV kit ? > seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA > as Glue logic.. > > that may remove the LAN / PHY from equation and permit made nice self > contained platform ;-) > > if no one yet ,i may willing to help work on this ,i was a senior > PCB designer whit some design backgrond .. > > Best 73! > Marc VE2OLM _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1409070984.0 From k5so at valornet.com Tue Aug 26 09:38:47 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Tue, 26 Aug 2014 10:38:47 -0600 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <3AD73732-607A-4AB5-96C3-5B78FB0B1477@valornet.com> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> <3AD73732-607A-4AB5-96C3-5B78FB0B1477@valornet.com> Message-ID: > ... will work fine with either a single powerful computer (SBC) connected to the hardware OR with a high performance computer connected to the hardware as we have traditionally done. I meant: single board computer (SBC). 73, Joe K5SO On Aug 26, 2014, at 10:35 AM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi John, > > I completely agree with your analysis and have in fact privately expressed to several people my concern regarding use of a (marginally powerful) single board computer in the mix. But keep in mind that the new protocol that Phil is contemplating will work fine with either a single powerful computer (SBC) connected to the hardware OR with a high performance computer connected to the hardware as we have traditionally done. > > Therefore the SBC development activity underway doesn?t limit things at all for those of us who would prefer to use a single high performance computer instead. Users of a single high performance computer can still exploit the new protocol and realize the same flexibility and performance benefits that Phil mentioned that are associated with the new proposed ethernet protocol. > > The Jetson board SBC approach is simply an activity that is running in parallel with the original architecture scheme. Whether you wish to use an SBC configuration or not is entirely optional and open to your personal preference. I?ve come to realize that we?re not losing anything at all by having some people working on SBC configurations in order to have low-performance hand held devices able to interface the hardware (if that happens to be your personal interest). > > 73, Joe K5SO > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlalonde at alphatronique.com Tue Aug 26 09:43:08 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Tue, 26 Aug 2014 12:43:08 -0400 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> Message-ID: <53FCB91C.1090209@alphatronique.com> HI mini-PCI-e may put on PCI-e whit common adapter ,then put on standard PC if need or may use PCI-e to PCI-e backplane + CPU of some sort ,so many possibility it need at last 2 lane for a decent SDR (make cation whit Bit Vs Byte) ADC was 12 Bit x 122Mhx and DAC was 14 bit x 122Mhz this may also double in future... so ~ 3.2Gbit/s integrating NVidia silicon onto an HPSDR ,not a thing that i doable at decent cost Best 73! Marc L. VE2OLM On 26/08/2014 11:08 AM, John Laur wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Ideas for discussion: > > First, isn't this similar to the architecture that has been > implemented by PA3FWM's wideband websdr for some time? > ADC->FPGA->Ethernet->FFT with GPU and then individual receivers only > have to grab the bins and do an IFFT? If so, it's a clear winner as > far as scaling the capabilities go. I am very excited to see the > excitement for it. But I am concerned with the discussion dwelling > around the Jetson board as being central and essential to this > architecture long-term although I do think it is valuable as a > motivator. > > For a hardware architecture that will hang around for a while and be > the most compatible, I would like to discuss the option of designing > instead for regular (non-mini) PCI-e. > > While it's great to have these 'fun-size' SBC's there is really > nothing that I have seen to conclude that NVidia or a 3rd party will > continue to ship such a thing as a developer or retail product with > extremely similar architecture and form factor over the long term. So > unless there is someone who wants to keep up with the hassle of > actually integrating NVidia silicon onto an HPSDR board and making a > wholly integrated system a la the Flex-6k, I do not think it is worth > exploring too far into that paradigm. Designing for the Jetson's > mini-pcie interface would severely limit future flexibility should the > product be dropped and limit the use of the HPSDR hardware in cases > where mini-pcie is not available on a board with a suitable CUDA GPU. > Plus, Jetson itself has a huge disadvantage (for the HPSDR server > application) of having only a single Ethernet interface. I understand > that there is still 16Mbps of bandwidth 'left over' (and that the > interface itself is full duplex) but that is an awfully limiting > margin considering the possibilities that exist with the architecture. > Yes; one could be added on USB without occupying the mini-PCIe, but at > the expense of the limited CPU resources. Running ethernet interfaces > at 99% capacity is a tricky business anyway. It would be nice to > simply eliminate that challenge. > > There is one thing we can be sure of though: NVidia will continue to > ship regular PCI-e graphics cards for the foreseeable future. > Depending on the version of CUDA required, an inexpensive NVidia > GeForce card will likely exceed Jetson's performance by quite a lot. A > small dedicated system with dual PCIe slots and a GPU can be designed > and built with specifications exceeding those of the Jetson board at > similar cost, and the same architecture can be implemented. I do not > see that the Jetson has any advantage over such system other than > perhaps power consumption or having fixed design. The problem of power > consumption is likely not to be a large concern in this application, > and the second problem can be eliminated by specifying a tested > reference design. > > * PCI-e is the fastest common interface available. Current standards > take speeds to 250gbps (PCI-e 4.0 x16), and even the lowest common > denominator (PCI-e 1.0 1x) is still 2gbps. > > * PCI-e can be bridged to Mini-PCIe, Thunderbolt, or Expresscard > interfaces with off-the-shelf hardware. > > * PCI-e supports DMA, RDMA, and peer to peer data transfer. Data can > be moved from HPDSR to GPU without involving the CPU. A passive PCI-e > backplane could be used as a future replacement for Atlas with the > ability to use off the shelf parts. > > * PCI-e is easy to interface in the modern Altera FPGAs with hardware > controllers and does not require the difficult task of writing IP for > 3rd party interface chips (Existing IP for things like USB 3.0 > controllers and 10gbE chips are licensed and generally not compatible > with open-source licenses. I believe this is one of the major pain > points with the current HPSDR FPGA efforts.) > > * PCI-e is generally backwards (and forwards!) compatible. So modern > high-bandwidth hardware can be designed and still used with older or > less powerful hosts. > > An external interface of some sort has the advantage that the RF bits > can be somewhat isolated from the noisy computer bits, but there are > ways to mitigate that and still use PCI-e, such as using a case design > that ensures the RF side is well shielded. The design could also be > broken into two parts with the ADC/DAC/Clocks isolated and connected > to the FPGA on a PCI-e card by means of line driver ICs and > off-the-shelf cables. > > Any thoughts from those more involved with the software or hardware design? > > 73, John KF5SAB > > > On Fri, Aug 22, 2014 at 10:31 PM, Phil Harman wrote: >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi Marc, >> >> Thanks for your email. >> >> We still have a way to go with fully proving the DFC idea but so far its looking good. >> >> We actually had this discussion a few minutes ago during the weekly Teamspeak session. >> >> Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia. There is no guarantee that what board replaces it, be it 64 bit Jeston or something completely different, may not have the same GIPO port. >> >> What does look viable is a board using miniPCIe since there is a good possibility that future SBCs will carry this interface. >> >> What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware. >> >> With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code, which is all ready proven to work. >> >> If such a PCB design is of interest to you then please lets discuss further. >> >> 73 Phil....VK6PH >> >> >> -----Original Message----- From: Marc Lalonde >> Sent: Saturday, August 23, 2014 10:31 AM >> To: hpsdr at lists.openhpsdr.org >> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development >> >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> Hi >> >> guess some one already work on a ADC /DAC Board that go on the expansion >> connector of the DEV kit ? >> seem to have 5 LVDS pair available + some GPIO ,so need probably FPGA >> as Glue logic.. >> >> that may remove the LAN / PHY from equation and permit made nice self >> contained platform ;-) >> >> if no one yet ,i may willing to help work on this ,i was a senior PCB >> designer whit some design backgrond .. >> >> Best 73! >> Marc VE2OLM > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1409071388.0 From hvh.net at gmail.com Tue Aug 26 10:40:02 2014 From: hvh.net at gmail.com (Hermann) Date: Tue, 26 Aug 2014 19:40:02 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: Message-ID: Dear John, all, thank you all for your thoughts. Here's my 2-cent: the discussion focus too much on Hardware, and the Jetson board is surely an experimental platform. It doesn't makes much sense to ponder upon if this board has one or two ethernet interfaces. Of course, this does matter if a certain architecture should be tested. Btw, the upcoming Tablets and Handhelds will have chips like the Tegra K1, and in a couple of years even more powerful devices. So, we will indeed have handhelds with super-computing power - at least in a certain sense. Hardware is subject to fast changes, but how do we keep up with the Software? Why do you think is Altera, e.g., providing an interface to OpenCL? Nvidia is doing a really great job in providing not only fast hardware, but also a complete programming model, together with all necessary tools. In a completely different domain (but also embedded), chip providers are building great hardware, with 6 or more cores etc etc., but don't tell the software architects how to program these fine controllers, or how to migrate software, which grew out of 20 years of development (and as such is invaluable). The 'multicore problem' is still not solved (some may claim they have), and the majority of algorithms and code (with some very few exceptions, like FFTs, or matrix multiplication) is NOT easily parallelized. Why does nobody (with very few but remarkable exceptions) take existing code (KISS Console, PowerSDR, cuSDR) and work on it to implement this or that feature? I receive so many emails and comments on the mailing lists, asking for new features. And if it's not going fast enough, people start declaring cuSDR as vaporware, hi. It is not much more difficult, than, as Joe, K5SO has reported so wonderful, start working on code for FPGAs. Hardware changes fast, Software not. The idea of open source is not only that the software is free. Much more important is that a lot of people start contributing to it. For me this is the main message from Phil's original post. 73, Hermann DL3HVH -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcrewson at cinci.rr.com Tue Aug 26 11:45:42 2014 From: rcrewson at cinci.rr.com (Rob Crewson) Date: Tue, 26 Aug 2014 14:45:42 -0400 Subject: [hpsdr] 'Cuda 6.5 Features and OverView'. Message-ID: <000c01cfc15d$f0843830$d18ca890$@cinci.rr.com> To anyone interested in this topic. I just watched a webinar from NVidia on their recent release of Cuda 6.5 -> 'Cuda 6.5 Features and OverView'. I took screenshots of the presentation slides (14) . The last one is of the chat board questions, one which pertained to the 'Jetson tk1' board. If you want a copy of either email me off list @ rcrewson at cinci.rr.com . 73, RobC VE3EW -------------- next part -------------- An HTML attachment was scrubbed... URL: From jra at febo.com Tue Aug 26 12:16:43 2014 From: jra at febo.com (John Ackermann N8UR) Date: Tue, 26 Aug 2014 15:16:43 -0400 Subject: [hpsdr] External T/R switch for PureSignal Message-ID: <53FCDD1B.5010803@febo.com> If you're interested in a kit to provide external T/R switching optimized for PureSignal setups, read on. If you've experimented with PureSignal, you know that the ANAN T/R switching isn't up to the task because (a) it shorts the receiver input to ground during TX, and (b) there is a lot of crosstalk within the switch/filter board. The combination means that you can't get a useful sampler signal into the radio without some sort of modification. Thanks to much help from KC9XG, I found that it's easy on the ANAN-10 to bypass the internal T/R by just removing the RX coax between the Hermes board and the amp board. Then, you can use the Hermes SMA RX connector and get TX from the ANT1 BNC connector. After that, all you need is an external switch. No new holes are required. (I don't own an ANAN-100 but as long as you can route the RX signal directly to the Hermes receive input, the same setup should work.) The external switch needs two relays: one to switch the antenna between TX and RX, and the second to switch the receiver path between antenna on RX and a signal sampler on TX. It needs good isolation for PureSignal (which is where my perfboard prototype with junkbox relays fell short). So, I've laid out a 3 inch (wide) by 1 inch (deep) circuit board with two BNC connectors (ANT and TX) and two SMA connectors (RX and SAMPLE). It uses the same relays as the Alex boards, and theoretically should have more than enough isolation for PureSignal. It should handle 100W. It takes 12V input and has a transistor switch for keying. This is early stage, and I'm just ordering Rev. A boards now. But I'm trying to see if there's enough interest to do a TAPR kit (all through-hole parts!) that would probably be in the $50 range. If you'd be interested, please drop a note off-list to jra at febo.com. 73, John 1409080603.0 From jbden at charter.net Tue Aug 26 12:47:31 2014 From: jbden at charter.net (John) Date: Tue, 26 Aug 2014 14:47:31 -0500 Subject: [hpsdr] AsRock SBC Message-ID: <53FCE453.8030503@charter.net> If some one is looking for a nice SBC, check out AsRock's line of j1900 mini-itx motherboards. I just buit one using memory and case I had on hand, for less than $200. It has built in dc-dc converter so it will use a netbook brick for power. Only uses about 10 Watts. Soon after I built it, they announced a new one using j2900 intel Pentium. I am not going to list all features, because they are on Asrock's site. John N4HXL 1409082451.0 From k5so at valornet.com Tue Aug 26 12:59:31 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Tue, 26 Aug 2014 13:59:31 -0600 Subject: [hpsdr] Timing Closure Field Guide Message-ID: All, In an effort to assist in making the timing closure tasks associated with OpenHPSDR firmware development less intimidating and easier for beginners to participate I have prepared a PDF document that describes a standardized procedure that I use for the task. The document may be downloaded from http://www.k5so.com/TimingClosureFieldGuide.pdf Please be aware that I do not claim to be an expert in this area and that the document may well have some errors and omissions; but I can guarantee that the document contains a decent sampling of the author?s personal bias. 73, Joe K5SO -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnlaur at gmail.com Tue Aug 26 13:27:22 2014 From: johnlaur at gmail.com (John Laur) Date: Tue, 26 Aug 2014 15:27:22 -0500 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: <53FCB91C.1090209@alphatronique.com> References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> <53FCB91C.1090209@alphatronique.com> Message-ID: All, Thank you for the good discussion. My intention was not to focus too much on the Jetson discussion actually; I do know that if the code runs on Jetson I can happily build a small linux machine that will also run it, so nobody is "locking" anyone into any particular thing. I just think the Jetson is a low mark to aim for. If it can do a realtime 30mHz FFT, so can basically any current GPU. Even low power cards like the GeForce 750 Ti will run circles around it, while drawing 60W and costing less. I think anyone who has ever compiled up the fosphor plugin on GNU Radio has probably lamented not having that view available all the time. So I wont beat on Jetson any more. I just thought while we were on the subject of architectures it would be a good time to cut to the chase on the bandwidth problem. While I will agree with Hermann that SDR hardware (and the HDL features of HPSDR) seem to be changing as fast or faster than SDR software in recent months, I also think it ought to be the other way around. On the big list of SDR's from Wikipedia http://en.wikipedia.org/wiki/List_of_software-defined_radios I note only 2 devices use PCIe. I think the hardware is changing largely because of all the ways that developers are choosing to deal with the problems of interface constraints; hardware that can filter this amount of data at this datarate is neither easy nor cheap to engineer. There is no need to go to this length if you can just move all the data in the first place. But if the GPU architecture is the way forward, it's just silly to put an intermediate interface that requires a lot of HDL work in the way. For a direct sampling design the most future proof design possible is to make sure the hardware is at minimum capable of sending the raw ADC/DAC/Clock data in and out at full datarate to an attached device. IMO the reason working with the SoCKit hardware and Scotty's boards is probably so nice is because the interface from the FPGA to the software is basically transparent. (This is half speculation as I have a SoCKit that I have used quite a bit but have not yet put funds together for a board set from Scotty) There is no ethernet PHY and framing and protocol to get at the DDC data; the CPU just opens a device and starts reading. If That eliminates a lot of complexity. But you could easily plug his board set into a different dev kit like this http://www.altera.com/products/devkits/altera/kit-cyclone-v-gt.html and with some (admitted) effort you could make yourself a prototype PCIe HPSDR card right now that could do DMA transfers of ADC samples right into GPU memory with the same sort of ease. This is the beauty of a high speed interconnect standard. In this case it is HSMC, useful only within a certain scope, but it makes the point I think. A comment for Marc: From what I have seen Mini-PCIe is generally only ever offered with a x1 interface with the exception of MXM, so it makes more sense to adapt a PCIe card to the mini-PCIe form factor than vice versa; that way the card can be designed as a 4x or such. (It can always be allowed to fall back to 1x) Anyway to sum it all up neatly, a single integrated board like Hermes with a Cyclone V SoC part on board that can be used standalone or plugged in and used as a PCIe card would be pretty attractive HPSDR platform, I gotta say. 73, John KF5SAB 1409084842.0 From rcrewson at cinci.rr.com Tue Aug 26 15:21:16 2014 From: rcrewson at cinci.rr.com (Rob Crewson) Date: Tue, 26 Aug 2014 18:21:16 -0400 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: <001501cfc17c$0e1ef8d0$2a5cea70$@cinci.rr.com> Excellent document Joe, short , single path , to the point. I've nodded off many time trying to get thru the Altera docs. 73, RobC - VE3EW -----Original Message----- From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Joe Martin K5SO Sent: Tuesday, August 26, 2014 4:00 PM To: HPSDR list Subject: [hpsdr] Timing Closure Field Guide ***** High Performance Software Defined Radio Discussion List ***** 1409091676.0 From n9vv at wowway.com Tue Aug 26 15:27:06 2014 From: n9vv at wowway.com (Ken N9VV (Win-7/64)) Date: Tue, 26 Aug 2014 17:27:06 -0500 Subject: [hpsdr] AsRock SBC In-Reply-To: <53FCE453.8030503@charter.net> References: <53FCE453.8030503@charter.net> Message-ID: <53FD09BA.30505@wowway.com> Hi John, I also like to point my Update Scanner (checks webpages for chances every day) at this website: http://linuxgizmos.com/category/boards/ LinuxGizmos seems to have quite a wide variety of SBC's listed and updated on an almost hourly basis all the best, 73 de Ken N9VV On 8/26/2014 2:47 PM, John wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > If some one is looking for a nice SBC, check out AsRock's line of j1900 > mini-itx motherboards. > I just buit one using memory and case I had on hand, for less than $200. > It has built in dc-dc converter so it will use a netbook brick for > power. Only uses about 10 Watts. Soon after I built it, they announced a > new one using j2900 intel Pentium. I am not going to list all features, > because they are on Asrock's site. > John N4HXL > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > 1409092026.0 From scotty at tonks.com Tue Aug 26 16:56:21 2014 From: scotty at tonks.com (Scott Cowling) Date: Tue, 26 Aug 2014 16:56:21 -0700 Subject: [hpsdr] Liva PC on sale at Newegg In-Reply-To: <53FCE453.8030503@charter.net> References: <53FCE453.8030503@charter.net> Message-ID: <7.0.1.0.2.20140826164456.0b4a5008@tonks.com> Hi all, Just saw this on the Newegg site (thanks to Ken, N9VV) and it looks very interesting. http://www.newegg.com/Product/Product.aspx?Item=N82E16856501007 While I have my share of low-power (and low-capability) PCs, this one looks especially intriguing. At only $132 including 2GB of RAM and 32GB eMMC drive, it is about as cheap as they come. Conduction cooled, Gigabit Ethernet, b/g/n WiFi, Bluetooth, dual monitor (HDMI + VGA) support, two USB ports (one 2.0, one 3.0) and a case; what more could you ask for? The special is only good through the end of August, so take a quick look if you are in the market for a new radio toy. Mine arrives Thursday. :-) We'll see if it has the guts to run GHPSDR3-Alex to put an HF1 receiver up on the QtRadio network! 73, Scotty WA2DFI 1409097381.0 From wb9qzb_groups at yahoo.com Tue Aug 26 17:29:19 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Tue, 26 Aug 2014 17:29:19 -0700 Subject: [hpsdr] Summer 2014 TAPR PSR Digital Communications Journal Available In-Reply-To: <1409098446.44945.YahooMailNeo@web140204.mail.bf1.yahoo.com> References: <1409098446.44945.YahooMailNeo@web140204.mail.bf1.yahoo.com> Message-ID: <1409099359.74958.YahooMailNeo@web140203.mail.bf1.yahoo.com> Summer 2014? TAPR PSR Digital Communications Journal? Available http://www.tapr.org/psr/psr126.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian13434 at yahoo.co.uk Wed Aug 27 02:23:23 2014 From: brian13434 at yahoo.co.uk (Brian D) Date: Wed, 27 Aug 2014 10:23:23 +0100 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: I've reverted to 4.1 firmware. The NaN problem has disappeared so it looks as if the angelia 4.2 firmware is the problem. Jae Stutzman wrote: I should have mentioned that I recently upgraded to 4.2 Angelia as well. So it could be either. I'll try downgrading back to 4.1 to see if that changes anything. I noticed it with TUN and it was reading out about 85W for each band. I was originally trying to find out if I was affected by the 10M winding issue. On Tue, Aug 26, 2014 at 4:54 AM, Brian D wrote: ***** High Performance Software Defined Radio Discussion List ***** Jae Stutzman wrote: > Is it just me or does the fwd pwr TX meter seem to be to be reading lower > than it should with this release? I was checking power outputs and it > seems to be about 15 watts lower than reality. Is this just me? I was > trying to adjust output power and that's when I realized it. I reset > databases just to be sure. I didn't notice this on 3.2.17. I haven't noticed it reading low but I've had several times it reading NaN for VSWR when tuning into the goood match of my test load. Not sure at this stage if it is the new version of HPSDR or my recent firmware upgrade to 4.2 (angelia). -- Brian D G3VGZ -- Brian D G3VGZ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1409131403.0 From k5so at valornet.com Wed Aug 27 06:10:22 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Wed, 27 Aug 2014 07:10:22 -0600 Subject: [hpsdr] Fwd: [apache-labs] PowerSDR/OpenHPSDR mRX PS v3.2.18 released In-Reply-To: References: <005601cfbe30$877604c0$96620e40$@net> <005d01cfbe34$b3052770$190f7650$@net> <009001cfbe49$eb92cbf0$c2b863d0$@net> <00ae01cfbe55$c0b8fc40$422af4c0$@net> Message-ID: There are unfortunately subtle physical differences board-to-board and chip-to-chip on all of the hardware we use. These differences can sometimes result in different behavior of firmware on some boards. There are no features coded differently in the firmware versions mentioned. Minor signal-path timing differences between v4.1 and v4.2 are all that distinguish the two versions, in this particular case. If an earlier version of firmware works better for your particular board than does a later version then by all means use what works for you. 73, Joe K5SO On Aug 27, 2014, at 3:23 AM, Brian D wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > I've reverted to 4.1 firmware. The NaN problem has disappeared so it looks > as if the angelia 4.2 firmware is the problem. > > > Jae Stutzman wrote: > I should have mentioned that I recently upgraded to 4.2 Angelia as well. So > it could be either. I'll try downgrading back to 4.1 to see if that changes > anything. I noticed it with TUN and it was reading out about 85W for each > band. I was originally trying to find out if I was affected by the 10M > winding issue. > > > On Tue, Aug 26, 2014 at 4:54 AM, Brian D wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Jae Stutzman wrote: > >> Is it just me or does the fwd pwr TX meter seem to be to be reading lower >> than it should with this release? I was checking power outputs and it >> seems to be about 15 watts lower than reality. Is this just me? I was >> trying to adjust output power and that's when I realized it. I reset >> databases just to be sure. I didn't notice this on 3.2.17. > > I haven't noticed it reading low but I've had several times it reading NaN > for VSWR when tuning into the goood match of my test load. Not sure at this > stage if it is the new version of HPSDR or my recent firmware upgrade to 4.2 > (angelia). > > > -- > Brian D > G3VGZ > 1409145022.0 From ad0es at ad0es.net Wed Aug 27 07:19:06 2014 From: ad0es at ad0es.net (AD0ES) Date: Wed, 27 Aug 2014 08:19:06 -0600 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: Hi, I have been slowly dipping my toes into the SDR pool, have a mercury rcvr setup functioning now. Excited about the direction new development is taking, especially in the area of moving more of the work from FPGA to a general class cpu/gpu. Next step for me is to setup with the tools necessary to write FPGA/gpu/openCL code. I spent some time on the Altera(?) site and went away totally confused. Are there tools available allowing one to design/write/compile FPGA code for these beasts without paying license fees or BEING CONNECTED to the net while using? I have no internet access at home and need a non-inet solution. If someone could provide a cookbook list of where/how to get the tools I believe it would get more people started down this path. tia, Steve AD0ES On Aug 26, 2014, at 1:59 PM, Joe Martin K5SO wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All, > > In an effort to assist in making the timing closure tasks associated with OpenHPSDR firmware development less intimidating and easier for beginners to participate I have prepared a PDF document that describes a standardized procedure that I use for the task. The document may be downloaded from 1409149146.0 From k5so at valornet.com Wed Aug 27 07:51:49 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Wed, 27 Aug 2014 08:51:49 -0600 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: <8D51197B-0E5F-4B20-86A6-AB8D93FB0713@valornet.com> Hi Steve, With regard to the necessary FGPA tools, you need only the free Quartus II program download from: https://www.altera.com/download/sw/dnl-sw-index.jsp at the bottom of the page is a window that allows you to select to download any version of Quartus II from v2.2 to v14.0. As you are working with Atlas-based boards I would suggest that the latest version for you work with should be v13.0 as later versions do not support the Cyclone II FPGA used in Penelope and the latest v14.0 does not support the Cyclone III FPGA used in Mercury. Quartus II will run just fine without being connect to the internet. You will receive a startup message that Quartus II can?t get to the Quartus website to check for updates but simply close the window and things will be fine. 73, Joe K5SO On Aug 27, 2014, at 8:19 AM, AD0ES wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > Hi, > > I have been slowly dipping my toes into the SDR pool, have a mercury rcvr setup functioning now. Excited about the > direction new development is taking, especially in the area of moving more of the work from FPGA to a general class > cpu/gpu. Next step for me is to setup with the tools necessary to write FPGA/gpu/openCL code. > > I spent some time on the Altera(?) site and went away totally confused. Are there tools available allowing one to > design/write/compile FPGA code for these beasts without paying license fees or BEING CONNECTED to the net while using? > I have no internet access at home and need a non-inet solution. > > If someone could provide a cookbook list of where/how to get the tools I believe it would get more people started down > this path. > > tia, > Steve AD0ES > 1409151109.0 From wb9qzb_groups at yahoo.com Wed Aug 27 07:47:34 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Wed, 27 Aug 2014 07:47:34 -0700 Subject: [hpsdr] DCC Proceedings Abstracts Announced - 2014 ARRL/TAPR Digital Communications Conference Austin, TX September 5-7, 2014 In-Reply-To: <1409150515.91658.YahooMailNeo@web140204.mail.bf1.yahoo.com> References: <1409150515.91658.YahooMailNeo@web140204.mail.bf1.yahoo.com> Message-ID: <1409150854.72388.YahooMailNeo@web140201.mail.bf1.yahoo.com> http://www.tapr.org/pub_dcc33.html DCC Proceedings Abstracts: 33rd ARRL and TAPR Digital Communications Conference September 5-7, 2014 ________________________________ High-Speed Wireless Networking in the UHF and Microwave Bands? by?David Bern, W2LNX?and?Keith Elkin, KB3TCB Abstract:?This paper discusses building an amateur radio wireless network using commercial off the shelf wireless networking equipment that is currently available. As an example, four Ubiquiti NanoStation M3 3.4 GHz digital radios are used to assemble a demonstration network of two wireless network links that operate on two different frequencies. In conclusion, the paper invites the amateur radio community to build a nationwide highspeed amateur radio wireless backbone network to connect all local amateur radio area community wireless networks. Proceedings Paper Clarifying the Amateur Bell 202 Modem? by?Kenneth W. Finnegan, W6KWF?and?Bridget Benson, PhD The Stream Control Transmission Protocol (SCTP) and Its Potential for Amateur Radio? by?Eduardo Gonzalez?,?Dr Stan McClellan?and?Dr Wuxu Peng SDR-based DATV-Express Exciter for Digital-ATV? by?Ken Konechy, W6HHC A Radioteletype Over-Sampling Software Decoder for Amateur Radio? by?Joseph J. Roby, Jr, K0JJR An HF Frequency-Division Multiplex (FDM) Modem? by?Steven Sampson, K5OKC Modulation - Demodulation Software Radio? by?Alex Schwarz VE7DXW?and?Guy Roels ON6MU Installing a LIF port into the FT-950 transceiver? by?Alex Schwarz, VE7DXW Installing a LIF port into the IC-756ProIII transceiver? by?Alex Schwarz, VE7DXW The European HAMNET - A Large Scale High Speed Radio Network? by?Jann Traschewski, DG8NGN Implementation of Basic Analog and Digital Modulation Schemes using a SDR Platform? by?Jose M. Valencia?and?Omar H. Longoria -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjablonski at att.net Wed Aug 27 11:06:22 2014 From: bjablonski at att.net (Barry Jablonski) Date: Wed, 27 Aug 2014 14:06:22 -0400 Subject: [hpsdr] Timing Closure Field Guide In-Reply-To: References: Message-ID: <53FE1E1E.6050304@att.net> Hi Steve. Here is a link to a PDF of Altera's "Intro to Quartus II": www.altera.com/literature/manual/intro_to_quartus2.pdf Hope it helps. Barry WB2ZXJ 1409162782.0 From scotty at tonks.com Thu Aug 28 13:43:06 2014 From: scotty at tonks.com (Scott Cowling) Date: Thu, 28 Aug 2014 13:43:06 -0700 Subject: [hpsdr] Success with GNURadio on LIVA PC! In-Reply-To: <53FE1E1E.6050304@att.net> References: <53FE1E1E.6050304@att.net> Message-ID: <7.0.1.0.2.20140828130549.056c7120@tonks.com> Hi all, This is not strictly HPSDR related, but I thought that most would be interested is the SDR capabilities of the ECS LIVA PC that is on sale at Newegg for $132 through Friday. I got the LIVA on Wednesday and assembled it. (Be careful with those little MMCX connectors for the WiFi antenna. I broke one of them and had to repair it, which was not fun.) I installed Ubuntu 14.04 from a USB flash drive, then downloaded and ran the GNURadio install script for version 3.7.4. Then I downloaded the SDRstick source block and followed the instructions to build and install it (only about 6 steps). I plugged in my HF1 and BeMicroSDK hardware to the USB port (for power) and the GigE port (for data). Amazingly, it came right up! The sample AM receiver flowgraph works, and at 384K bandwidth I can hear (and see) AM broadcast stations with no dropouts. This is pretty exciting for such a small, low-power PC! When I go to 1.25MHz bandwidth, the receiver still works, but the PC just can't keep the graphics on the screen updated. I haven't tweaked any priorities yet, but it looks like 1.25MHz is a bit too much for this "little PC that could"! I will bring this setup to DCC next weekend to demo. 73, Scotty WA2DFI 1409258586.0 From g4hup at btinternet.com Thu Aug 28 15:01:06 2014 From: g4hup at btinternet.com (dave powis) Date: Thu, 28 Aug 2014 23:01:06 +0100 Subject: [hpsdr] FS - Hermes set-up Message-ID: <1409263266.99171.YahooMailNeo@web87703.mail.ir2.yahoo.com> For sale - my Hermes set up, comprising: TAPR Hermes mounted in Hammond case, with additional chip heatsink and external power connector N8UR breakout board for J16 Munin PA kit with heatsink and Hammond case (not assembled). Looking for ?800.? Shipping to be discussed - preference to UK sale. Also available Alex Tx/Rx Filter set in housing? - assembled, with cables Looking for ?300. Shipping to be discussed - preference to UK sale. Please contact me off-list at g4hup-at-btinternet-dot-com Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From lstoskopf at cox.net Thu Aug 28 21:05:17 2014 From: lstoskopf at cox.net (lstoskopf at cox.net) Date: Fri, 29 Aug 2014 0:05:17 -0400 Subject: [hpsdr] Success with GNURadio on LIVA PC! In-Reply-To: Message-ID: <20140829000517.QTPFP.168732.imail@eastrmwml107> Great. Some of us did the Kickstarter thing to have the talks put on HamTV (I think). Hit him up for a quick segment on your setup and operation. Awaiting the new AC9 board. N0UU 1409285117.0 From jkelly at verizon.net Fri Aug 29 03:07:06 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 29 Aug 2014 06:07:06 -0400 Subject: [hpsdr] WTB Funcube Dongle Pro Message-ID: <0NB2007XYC3WYBA0@vms173015.mailsrvcs.net> U2VuZCBlbWFpbCB0bzoKCksyU0RSIGF0IHZlcml6b24ubmV0CgpKZWZm 1409306826.0 From wb9qzb_groups at yahoo.com Fri Aug 29 12:30:21 2014 From: wb9qzb_groups at yahoo.com (Mark Thompson) Date: Fri, 29 Aug 2014 12:30:21 -0700 Subject: [hpsdr] ARRL/TAPR DCC Speaker Schedule Announced, Austin, TX, 9/5 - 9/7/14 (Walk-In Registrations at DCC Welcome) In-Reply-To: <8D191D64470CED4-1EF4-448A@webmail-vd010.sysops.aol.com> References: <1409340051.42235.YahooMailNeo@web140202.mail.bf1.yahoo.com> <8D191D5E158017D-1EF4-443D@webmail-vd010.sysops.aol.com> <8D191D64470CED4-1EF4-448A@webmail-vd010.sysops.aol.com> Message-ID: <1409340621.78960.YahooMailNeo@web140201.mail.bf1.yahoo.com> DCC Speaker Schedule Announced 2014 ARRL/TAPR Digital Communications Conference Austin, TX September 5 - 7, 2014 http://www.tapr.org/pdf/DCC_2014_Schedule_2014-08-27.pdf Register for the DCC Walk-in registrations at DCC are very welcome. Online Registration Form https://www.tapr.org/dccregistration.php Pre-registration will close on August 30th to allow the office staff to complete preparations (print badges and stuff envelopes) and travel to the conference. Use of the on-line registration form after August 30th is encouraged, as it will save time at the registration desk filling in hard copy forms and wait for credit card processing.. Tucson Amateur Packet Radio Phone: (972) 671-TAPR (8277) Contact TAPR Office: http://www.tapr.org/inforequest.php -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkelly at verizon.net Fri Aug 29 15:17:12 2014 From: jkelly at verizon.net (Jeff Kelly) Date: Fri, 29 Aug 2014 18:17:12 -0400 Subject: [hpsdr] WTB Funcube Dongle Pro In-Reply-To: <0NB2007XYC3WYBA0@vms173015.mailsrvcs.net> References: <0NB2007XYC3WYBA0@vms173015.mailsrvcs.net> Message-ID: <594C7EC51FA641619B6FBBD3FBAEFBAE@JeffPC> Thank you got one. Jeff -----Original Message----- From: Jeff Kelly Sent: Friday, August 29, 2014 6:07 To: hpsdr at openhpsdr.org Subject: [hpsdr] WTB Funcube Dongle Pro ***** High Performance Software Defined Radio Discussion List ***** Send email to: K2SDR at verizon.net Jeff _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1409350632.0 From w5wc at windstream.net Fri Aug 29 16:54:12 2014 From: w5wc at windstream.net (Doug Wigley) Date: Fri, 29 Aug 2014 18:54:12 -0500 Subject: [hpsdr] PowerSDR/OpenHPSDR mRX PS v3.2.19 released Message-ID: <00ad01cfc3e4$88b755f0$9a2601d0$@net> All, PowerSDR/OpenHPSDR mRX PS v3.2.19 has been released. Bug fixes added for the following problems: - APF text field in the VFOA window masked part of the VHF frequency. - Unable to use the DJ Console with CTUN enabled. Added colors to the diversity "Enable" button. Green = ON, Red = OFF. No database reset required! This release can be downloaded from the openhpsdr.org website. http://openhpsdr.org/download.php 73, Doug W5WC 1409356452.0 From mlalonde at alphatronique.com Fri Aug 29 17:29:08 2014 From: mlalonde at alphatronique.com (Marc Lalonde) Date: Fri, 29 Aug 2014 20:29:08 -0400 Subject: [hpsdr] Success with GNURadio on LIVA PC! In-Reply-To: <7.0.1.0.2.20140828161242.05444838@tonks.com> References: <53FE1E1E.6050304@att.net> <7.0.1.0.2.20140828130549.056c7120@tonks.com> <53FFA0FB.2090201@alphatronique.com> <7.0.1.0.2.20140828161242.05444838@tonks.com> Message-ID: <54011AD4.2080806@alphatronique.com> Hi first that really small PC ! next it require a "UEFI" bootable USB key AND a 64Bit win 8.1 for work anything else fail to boot and/or install ,i lost big part of my day figure it ... i make work whit decent performance of 2 or less decoding WSJT-X (not forget the NTP server) JT65HF-109 one that not work JT65-HF HB9HQX remain on "receiving" so whit my KX3 i made nice portable JT65 setup and\or monitor for 6M opening 73 .. Marc L VE2OLM On 28/08/2014 7:13 PM, Scott Cowling wrote: > Hi Marc, > > Sounds like a good use for one! I would like to hear about your setup > when you get it running. > > 73, > Scotty WA2DFI > > At 17:36 2014-08-28 -0400, you wrote: >> Hi >> >> Thank i have order one for try to use it for monitor 6M Band opening >> whit JT65A >> >> 73 >> Marc VE2OLM >> >> On 28/08/2014 4:43 PM, Scott Cowling wrote: >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> Hi all, >>> >>> This is not strictly HPSDR related, but I thought that most would be >>> interested is the SDR capabilities of the ECS LIVA PC that is on >>> sale at Newegg for $132 through Friday. >>> >>> I got the LIVA on Wednesday and assembled it. (Be careful with those >>> little MMCX connectors for the WiFi antenna. I broke one of them and >>> had to repair it, which was not fun.) >>> >>> I installed Ubuntu 14.04 from a USB flash drive, then downloaded and >>> ran the GNURadio install script for version 3.7.4. Then I downloaded >>> the SDRstick source block and followed the instructions to build and >>> install it (only about 6 steps). >>> >>> I plugged in my HF1 and BeMicroSDK hardware to the USB port (for >>> power) and the GigE port (for data). >>> >>> Amazingly, it came right up! The sample AM receiver flowgraph works, >>> and at 384K bandwidth I can hear (and see) AM broadcast stations >>> with no dropouts. This is pretty exciting for such a small, >>> low-power PC! >>> >>> When I go to 1.25MHz bandwidth, the receiver still works, but the PC >>> just can't keep the graphics on the screen updated. I haven't >>> tweaked any priorities yet, but it looks like 1.25MHz is a bit too >>> much for this "little PC that could"! >>> >>> I will bring this setup to DCC next weekend to demo. >>> >>> 73, >>> Scotty WA2DFI >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: >>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > 1409358548.0 From aa8k73 at gmail.com Fri Aug 29 19:31:47 2014 From: aa8k73 at gmail.com (AA8K73 GMail) Date: Fri, 29 Aug 2014 22:31:47 -0400 Subject: [hpsdr] TeamSpeak audio 2014/Aug/30 Message-ID: <54013793.3030108@gmail.com> The 30/Aug TeamSpeak mp3 (67 minutes) 64 kbps is available at: < http://www.hamsdr.com/dnld.aspx?id=3513 > or < http://www.hamsdr.com/dnld.aspx > Only silence truncation editing was done on this recording. 1409365907.0 From dc6ny at gmx.de Sun Aug 31 02:49:41 2014 From: dc6ny at gmx.de (Helmut Oeller) Date: Sun, 31 Aug 2014 11:49:41 +0200 Subject: [hpsdr] openHPSDR at the forefront of SDR development In-Reply-To: References: <53F7FD0F.6020301@alphatronique.com> <2AA066BF93AE4D988C72ACBEC30B6446@ShackPC2> <53FCB91C.1090209@alphatronique.com> Message-ID: <000001cfc500$e38379b0$aa8a6d10$@de> Hi, I read a topical notification of the USB Promoter Group (HP, Intel, MS, Renesas Elec, TI ) that USB 3.1 will be already available end of 2014. This smart (cheap) interface could be one option for a fast 10 Gbit/s connection of future broadband DDC/DUC hardware and versatile computer architectures. I think it's certainly worth to watch further progress and market. 73, Helmut, DC6NY -----Urspr?ngliche Nachricht----- Von: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] Im Auftrag von John Laur Gesendet: Dienstag, 26. August 2014 22:27 An: HPSDR list Betreff: Re: [hpsdr] openHPSDR at the forefront of SDR development ***** High Performance Software Defined Radio Discussion List ***** All, Thank you for the good discussion. My intention was not to focus too much on the Jetson discussion actually; I do know that if the code runs on Jetson I can happily build a small linux machine that will also run it, so nobody is "locking" anyone into any particular thing. I just think the Jetson is a low mark to aim for. If it can do a realtime 30mHz FFT, so can basically any current GPU. Even low power cards like the GeForce 750 Ti will run circles around it, while drawing 60W and costing less. I think anyone who has ever compiled up the fosphor plugin on GNU Radio has probably lamented not having that view available all the time. So I wont beat on Jetson any more. I just thought while we were on the subject of architectures it would be a good time to cut to the chase on the bandwidth problem. While I will agree with Hermann that SDR hardware (and the HDL features of HPSDR) seem to be changing as fast or faster than SDR software in recent months, I also think it ought to be the other way around. On the big list of SDR's from Wikipedia http://en.wikipedia.org/wiki/List_of_software-defined_radios I note only 2 devices use PCIe. I think the hardware is changing largely because of all the ways that developers are choosing to deal with the problems of interface constraints; hardware that can filter this amount of data at this datarate is neither easy nor cheap to engineer. There is no need to go to this length if you can just move all the data in the first place. But if the GPU architecture is the way forward, it's just silly to put an intermediate interface that requires a lot of HDL work in the way. For a direct sampling design the most future proof design possible is to make sure the hardware is at minimum capable of sending the raw ADC/DAC/Clock data in and out at full datarate to an attached device. IMO the reason working with the SoCKit hardware and Scotty's boards is probably so nice is because the interface from the FPGA to the software is basically transparent. (This is half speculation as I have a SoCKit that I have used quite a bit but have not yet put funds together for a board set from Scotty) There is no ethernet PHY and framing and protocol to get at the DDC data; the CPU just opens a device and starts reading. If That eliminates a lot of complexity. But you could easily plug his board set into a different dev kit like this http://www.altera.com/products/devkits/altera/kit-cyclone-v-gt.html and with some (admitted) effort you could make yourself a prototype PCIe HPSDR card right now that could do DMA transfers of ADC samples right into GPU memory with the same sort of ease. This is the beauty of a high speed interconnect standard. In this case it is HSMC, useful only within a certain scope, but it makes the point I think. A comment for Marc: From what I have seen Mini-PCIe is generally only ever offered with a x1 interface with the exception of MXM, so it makes more sense to adapt a PCIe card to the mini-PCIe form factor than vice versa; that way the card can be designed as a 4x or such. (It can always be allowed to fall back to 1x) Anyway to sum it all up neatly, a single integrated board like Hermes with a Cyclone V SoC part on board that can be used standalone or plugged in and used as a PCIe card would be pretty attractive HPSDR platform, I gotta say. 73, John KF5SAB _______________________________________________ HPSDR Discussion List To post msg: hpsdr at openhpsdr.org Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org HPSDR web page: http://openhpsdr.org Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ 1409478581.0 From k5so at valornet.com Sun Aug 31 09:29:55 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 31 Aug 2014 10:29:55 -0600 Subject: [hpsdr] Orion/ANAN-200D Orion_v2.7 firmware package release Message-ID: <4571643A-37A2-4780-97D1-3D70793B24C8@valornet.com> All, Orion_v2.7 firmware package is available for download from http://www.k5so.com/HPSDR_downloads.html This version of firmware fixes a failure to key an external amplifiler via the PTT output connector when keyed via the external PTT input pin of the accessory jack when in CW mode and improper behavior of non-breakin CW PTT functionality. I have alerted Phil and Abhi that this issue, corrected earlier in Angelia firmware, exists in any of our firmware designs that have implemented CW generated withing the FPGA, including Hermes and Atlas-based systems. It is my expectation that they will shortly release new versions of their respective firmware packages to include this fix which has now already been applied to the Angelia and Orion firmware. 73, Joe K5SO 1409502595.0 From wb4gcs at wb4gcs.org Sun Aug 31 11:29:21 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Sun, 31 Aug 2014 14:29:21 -0400 Subject: [hpsdr] Multiple Metis on one Ethernet Message-ID: <54036981.2020709@wb4gcs.org> All: Have one HPSDR running. Building the second. FOr now, mercury is set to obtain IP address via DHCP. Any problems putting the second one on the network to update firmware in my very old mercury and penny boards? Thanks & 73, Jim wb4gcs at amsat.org --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1409509761.0 From beford at myfairpoint.net Sun Aug 31 13:01:55 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Sun, 31 Aug 2014 16:01:55 -0400 Subject: [hpsdr] Munin amp kits for sale Message-ID: I purchased two complete kits for Munin when they were offered by Don, K3DLW, but have not built either yet. I would be willing to sell both for what I paid, plus postage. This also includes the PC boards , all components, heat sinks and copper heat spreaders. That would come to $170 each total, including Priority mail to your US address. Check, Money Order, or PayPal would be fine. Please reply off-list. mycall at arrl dot net Thanks, Bruce/N1RX -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 13:30:30 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 15:30:30 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 Message-ID: After about 3 hours worth of work and a few workarounds, I made my first QSO on 20 meters under Linux! I used MonoDevelop as the IDE for the C# KISS solution. I had to make a couple of changes for the P/Invokes of the fftw3f library and some of the Networking calls, which are still not implemented within the Mono CLR. The performance is quite good, I'll compare it to my Windows box to see the differences. Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. I'll document my changes and the dependencies that I installed to make it work soon. Thanks everyone for the welcome and thanks to the authors of KISS Konsole for making the porting easy :) 73, Jae - K5JAE -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 13:36:38 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 15:36:38 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: The link should not have the following '.' at the end. Here it is again: http://i.imgur.com/AsJ4pSE.png On Sun, Aug 31, 2014 at 3:30 PM, Jae Stutzman wrote: > After about 3 hours worth of work and a few workarounds, I made my first > QSO on 20 meters under Linux! > > I used MonoDevelop as the IDE for the C# KISS solution. I had to make a > couple of changes for the P/Invokes of the fftw3f library and some of the > Networking calls, which are still not implemented within the Mono CLR. The > performance is quite good, I'll compare it to my Windows box to see the > differences. > > Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. > I'll document my changes and the dependencies that I installed to make it > work soon. > > Thanks everyone for the welcome and thanks to the authors of KISS Konsole > for making the porting easy :) > > > 73, > > Jae - K5JAE > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.frohne at wallawalla.edu Sun Aug 31 15:12:51 2014 From: rob.frohne at wallawalla.edu (Rob Frohne) Date: Sun, 31 Aug 2014 14:12:51 -0800 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: That's neat Jae! 73, Rob KL7NA On August 31, 2014 12:36:38 PM AKDT, Jae Stutzman wrote: >***** High Performance Software Defined Radio Discussion List ***** > > > >------------------------------------------------------------------------ > >The link should not have the following '.' at the end. Here it is >again: >http://i.imgur.com/AsJ4pSE.png > > > >On Sun, Aug 31, 2014 at 3:30 PM, Jae Stutzman >wrote: > >> After about 3 hours worth of work and a few workarounds, I made my >first >> QSO on 20 meters under Linux! >> >> I used MonoDevelop as the IDE for the C# KISS solution. I had to make >a >> couple of changes for the P/Invokes of the fftw3f library and some of >the >> Networking calls, which are still not implemented within the Mono >CLR. The >> performance is quite good, I'll compare it to my Windows box to see >the >> differences. >> >> Here is a link to a screenshot of how it looks: >http://imgur.com/AsJ4pSE. >> I'll document my changes and the dependencies that I installed to >make it >> work soon. >> >> Thanks everyone for the welcome and thanks to the authors of KISS >Konsole >> for making the porting easy :) >> >> >> 73, >> >> Jae - K5JAE >> >> >> >> > > >------------------------------------------------------------------------ > >_______________________________________________ >HPSDR Discussion List >To post msg: hpsdr at openhpsdr.org >Subscription help: >http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >HPSDR web page: http://openhpsdr.org >Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wb4gcs at wb4gcs.org Sun Aug 31 14:57:25 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Sun, 31 Aug 2014 17:57:25 -0400 Subject: [hpsdr] Trouble updating Mercury firmware Message-ID: <54039A45.8020804@wb4gcs.org> All: I am finally assembling the system I purchased in pieces long ago from TAPR. I have successfully updated Metis firmware to the latest. I have installed J1 in Metis to put it in bootloader mode. I have installed J7 (last JTAG) jumper on Mercury. Running HPSDRProgrammer V2 version 2.0.4.0 All the LEDs on Mercury that the manual says should be lit are. When I click DISCOVER, Mercury is not found, and I get an error message telling me to "Make sure the correct interface is attached. There is only one interface -- the ethernet interface on the computer. Any suggestions?? Thanks & 73, Jim wb4gcs at amsat.org --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com 1409522245.0 From k5jae at stutzman.net Sun Aug 31 15:54:22 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 17:54:22 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: On a whim, I thought I might try the Jetson TK1 board with mono/kiss konsole. After working out the dependencies, it appears to run OK (I haven't transmitted yet). Anything beyond 96000 sample rate will give audio distortion on the receive. If I choose 192000 and then select NR, it really goes off the rails. Keep in mind that this is completely running within the ARM hard float CPU, which is using the original libfftw3 FFT library. Utilizing a CUDA optimized FFT library would probably give a lot more headroom. Both the spectrum and waterfall displays are ok with some slight hiccup that correspond to audio blips. 73, Jae - K5JAE On Sun, Aug 31, 2014 at 5:12 PM, Rob Frohne wrote: > That's neat Jae! > > 73, > Rob > KL7NA > > On August 31, 2014 12:36:38 PM AKDT, Jae Stutzman > wrote: >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> The link should not have the following '.' at the end. Here it is again: >> http://i.imgur.com/AsJ4pSE.png >> >> >> >> On Sun, Aug 31, 2014 at 3:30 PM, Jae Stutzman wrote: >> >>> After about 3 hours worth of work and a few workarounds, I made my first >>> QSO on 20 meters under Linux! >>> >>> I used MonoDevelop as the IDE for the C# KISS solution. I had to make a >>> couple of changes for the P/Invokes of the fftw3f library and some of the >>> Networking calls, which are still not implemented within the Mono CLR. The >>> performance is quite good, I'll compare it to my Windows box to see the >>> differences. >>> >>> Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. >>> I'll document my changes and the dependencies that I installed to make it >>> work soon. >>> >>> Thanks everyone for the welcome and thanks to the authors of KISS >>> Konsole for making the porting easy :) >>> >>> >>> 73, >>> >>> Jae - K5JAE >>> >>> >>> >>> >> ------------------------------ >> >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5so at valornet.com Sun Aug 31 16:09:32 2014 From: k5so at valornet.com (Joe Martin K5SO) Date: Sun, 31 Aug 2014 17:09:32 -0600 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: <6B339E1F-4D1A-4AF4-9404-386B050807B3@valornet.com> Congratulations, Jae! That?s excellent news! I have just this past Thursday assembled a new computer system to allow me to begin exploring Linux. I have installed Ubuntu, Synaptic, Mono-complete, MonoDevelop and am anxious to get rolling on porting some of my Windows C# radio astronomy apps that I have written over to Linux. I am ecstatic to hear that you have KISS ported over now (in such a brief time too!!) and I am very interested to see how you did it. Also, I too have a strong interest in porting PowerSDR over to Linux and I have heard of your vast experience in such porting activities. I am quite excited to learn of any progress that you make there so please do give us updates as to your progress. I, naively of course, intended to give it a try myself as soon as I gain more familiarity with Linux, and Mono in particular. I currently use Visual Studio 2013 to make mods to the PowerSDR code from time to time but I?m not a professional programmer and barely squeak along with VS to be truthful; but I?m continuing to learn all the time and am getting more proficient, I hope. I am a complete newbie with respect to Linux so please don?t be overly brief in your ?how to? descriptions or they?ll go completely over my head for sure. Thanks, and congrats again! 73, Joe K5SO 1409526572.0 From g3vbv at blueyonder.co.uk Sun Aug 31 16:20:51 2014 From: g3vbv at blueyonder.co.uk (Sid Boyce) Date: Mon, 01 Sep 2014 00:20:51 +0100 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: <5403ADD3.2020209@blueyonder.co.uk> Neat. Back in May 2013 I posted the following but didn't get a reply. This was using the .exe under Crossover Office. ------------------------------------------------------------------------------------ For curiosity value mainly. Just seeing if anyone has an idea what's happening. Appending screenshots exceeds the allowed email limit. I select HERMES and when I click ON I get a string of these messages, it sees Hermes on 192.168.10.77 then the 127.12.34.56 Metis stuff, Metis is not selected, only Hermes with 2.4 firmware. Found a Metis/Hermes/Griffin. Checking whether it qualifies Metis IP from IP Header = 192.168.10.77 Metis MAC address from payload = 00-04-A3-6A-21-BE Not on subnet of host adapter! Adapter IP 127.12.34.56, Adapter mask 255.255.255.255 No data from Port = Ready to receive.... raw Discovery data = EF-FE-02-00-04-A3-6A-21-BE-18-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 -01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 ----------------------------------------------------------------------------------------------------------------------- 73 ... Sid. On 31/08/14 21:30, Jae Stutzman wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > > > After about 3 hours worth of work and a few workarounds, I made my > first QSO on 20 meters under Linux! > > I used MonoDevelop as the IDE for the C# KISS solution. I had to make > a couple of changes for the P/Invokes of the fftw3f library and some > of the Networking calls, which are still not implemented within the > Mono CLR. The performance is quite good, I'll compare it to my Windows > box to see the differences. > > Here is a link to a screenshot of how it looks: > http://imgur.com/AsJ4pSE. I'll document my changes and the > dependencies that I installed to make it work soon. > > Thanks everyone for the welcome and thanks to the authors of KISS > Konsole for making the porting easy :) > > > 73, > > Jae - K5JAE > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 16:25:48 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 18:25:48 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: <6B339E1F-4D1A-4AF4-9404-386B050807B3@valornet.com> References: <6B339E1F-4D1A-4AF4-9404-386B050807B3@valornet.com> Message-ID: Joe, This is obviously a proof of concept at this point. Some of the issues I experienced years ago with Mono and WinForms are still there. Namely, rendering issues. On Windows, WinForms is a thin wrapper on top of native Windows libraries. On Linux, the Mono team wrote the entire library in managed code before diving into the native X Windows UI layer. What I find is that initial widget rendering is a bit slow and then size and location of widgets don't always render correctly. However, the UI seems usable. I'll definitely relay my findings to this group. More to follow :) 73, Jae - K5JAE On Aug 31, 2014 6:09 PM, "Joe Martin K5SO" wrote: > Congratulations, Jae! That?s excellent news! > > I have just this past Thursday assembled a new computer system to allow me > to begin exploring Linux. I have installed Ubuntu, Synaptic, > Mono-complete, MonoDevelop and am anxious to get rolling on porting some of > my Windows C# radio astronomy apps that I have written over to Linux. I am > ecstatic to hear that you have KISS ported over now (in such a brief time > too!!) and I am very interested to see how you did it. > > Also, I too have a strong interest in porting PowerSDR over to Linux and I > have heard of your vast experience in such porting activities. I am quite > excited to learn of any progress that you make there so please do give us > updates as to your progress. I, naively of course, intended to give it a > try myself as soon as I gain more familiarity with Linux, and Mono in > particular. I currently use Visual Studio 2013 to make mods to the > PowerSDR code from time to time but I?m not a professional programmer and > barely squeak along with VS to be truthful; but I?m continuing to learn all > the time and am getting more proficient, I hope. > > I am a complete newbie with respect to Linux so please don?t be overly > brief in your ?how to? descriptions or they?ll go completely over my head > for sure. > > Thanks, and congrats again! > > 73, Joe K5SO > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k5jae at stutzman.net Sun Aug 31 17:03:01 2014 From: k5jae at stutzman.net (Jae Stutzman) Date: Sun, 31 Aug 2014 19:03:01 -0500 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: <5403ADD3.2020209@blueyonder.co.uk> Message-ID: Sid, I've only used CrossOver for a couple of things. There is a big difference to running and exe within CX and Mono. First, CX is a reimplementation of win32/64 native libraries under Linux and libc. It intends to allow win apps to run as though they are on windows. This means you install .NET on top of CX to run C# apps. It has been moderately successful and a huge undertaking! Mono, on the other hand is a reimplementation of the CLR/CLI. It doesn't bring in any win32/64 APIs and is a clean room implementation. It would be analogous to the JVM running on Linux vs running on Windows, except that MS didn't provide a Linux version so the OSS community wrote it themselves. I view CX as a compromise to bring windows applications to Linux. I view Mono as a first class development and runtime environment where Linux apps can be made and executed. That said. I like cross platform development. With careful consideration an app can look and run as if native on many different platforms. As far as your log, I'm not sure what was going on! Except it looks like it had something to do with the network interface. 73, Jae > On Aug 31, 2014 6:20 PM, "Sid Boyce" wrote: >> >> ***** High Performance Software Defined Radio Discussion List ***** >> >> >> Neat. >> Back in May 2013 I posted the following but didn't get a reply. This was using the .exe under Crossover Office. >> ------------------------------------------------------------------------------------ >> For curiosity value mainly. >> Just seeing if anyone has an idea what's happening. >> Appending screenshots exceeds the allowed email limit. >> >> I select HERMES and when I click ON I get a string of these messages, it sees Hermes on 192.168.10.77 then the 127.12.34.56 Metis stuff, Metis is not selected, only Hermes with 2.4 firmware. >> >> Found a Metis/Hermes/Griffin. Checking whether it qualifies >> Metis IP from IP Header = 192.168.10.77 >> Metis MAC address from payload = 00-04-A3-6A-21-BE >> Not on subnet of host adapter! Adapter IP 127.12.34.56, Adapter mask 255.255.255.255 >> No data from Port = >> Ready to receive.... >> raw Discovery data = EF-FE-02-00-04-A3-6A-21-BE-18-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 >> -01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01-01 >> ----------------------------------------------------------------------------------------------------------------------- >> 73 ... Sid. >> >> On 31/08/14 21:30, Jae Stutzman wrote: >>> >>> ***** High Performance Software Defined Radio Discussion List ***** >>> >>> >>> >>> After about 3 hours worth of work and a few workarounds, I made my first QSO on 20 meters under Linux! >>> >>> I used MonoDevelop as the IDE for the C# KISS solution. I had to make a couple of changes for the P/Invokes of the fftw3f library and some of the Networking calls, which are still not implemented within the Mono CLR. The performance is quite good, I'll compare it to my Windows box to see the differences. >>> >>> Here is a link to a screenshot of how it looks: http://imgur.com/AsJ4pSE. I'll document my changes and the dependencies that I installed to make it work soon. >>> >>> Thanks everyone for the welcome and thanks to the authors of KISS Konsole for making the porting easy :) >>> >>> >>> 73, >>> >>> Jae - K5JAE >>> >>> >>> >>> >>> >>> _______________________________________________ >>> HPSDR Discussion List >>> To post msg: hpsdr at openhpsdr.org >>> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >>> HPSDR web page: http://openhpsdr.org >>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ >> >> >> >> -- >> 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 >> >> >> _______________________________________________ >> >> HPSDR Discussion List >> To post msg: hpsdr at openhpsdr.org >> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org >> HPSDR web page: http://openhpsdr.org >> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wp4o at tampabay.rr.com Sun Aug 31 17:42:30 2014 From: wp4o at tampabay.rr.com (ed) Date: Sun, 31 Aug 2014 20:42:30 -0400 Subject: [hpsdr] anan 100 forsale Message-ID: <000001cfc57d$9cad2310$d6076930$@tampabay.rr.com> Selling my extra ANAN 100 has new Smps regulator and VCXO Runs very cool. E mail me if interested. Thanks and 73, Ed KK4x, Tampa Florida -------------- next part -------------- An HTML attachment was scrubbed... URL: From kv0s.dave at gmail.com Sun Aug 31 18:15:24 2014 From: kv0s.dave at gmail.com (Dave Larsen) Date: Sun, 31 Aug 2014 20:15:24 -0500 Subject: [hpsdr] Trouble updating Mercury firmware In-Reply-To: <54039A45.8020804@wb4gcs.org> References: <54039A45.8020804@wb4gcs.org> Message-ID: Jim Almost right There are two programs, HPSDRProgrammer V2 only talks to boards with ethernet sockets and does not need the j1 jumper but it will not program through a JTAG port. the second program HPSDRBootloader is for use in the Bootloader mode as you specified. If you follow your steps, EXCEPT use HPSDRBootloader it should work.. HPSDRBootloader uses the pcap library, the J1 jumper and a raw Ethernet packets and cane be used as a JTAG programmer for boards with no Ethernet connector. HPSDRProgrammer V2 is use UDP, no jumper and old firmware newer that 2.3, This is convenients for update firmware without opening the box. But if the old firmware is broke it will not work. PS. HPSDRProgrammer V1.6 does both tasks but people got confused different problem and what part of the program when with each task. Dave KV0S HPSDRProgrammer V2 and HPSDRBootloader Programmer and Maintainer On Sun, Aug 31, 2014 at 4:57 PM, Jim Sanford wrote: > ***** High Performance Software Defined Radio Discussion List ***** > > All: > I am finally assembling the system I purchased in pieces long ago from > TAPR. > > I have successfully updated Metis firmware to the latest. > > I have installed J1 in Metis to put it in bootloader mode. > > I have installed J7 (last JTAG) jumper on Mercury. > > Running HPSDRProgrammer V2 version 2.0.4.0 > > All the LEDs on Mercury that the manual says should be lit are. > > When I click DISCOVER, Mercury is not found, and I get an error message > telling me to "Make sure the correct interface is attached. There is only > one interface -- the ethernet interface on the computer. > > Any suggestions?? > > Thanks & 73, > Jim > wb4gcs at amsat.org > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/ > listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > -- KV0S - Dave Larsen Columbia, MO, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: From wb4gcs at wb4gcs.org Sun Aug 31 18:21:11 2014 From: wb4gcs at wb4gcs.org (Jim Sanford) Date: Sun, 31 Aug 2014 21:21:11 -0400 Subject: [hpsdr] Trouble updating Mercury firmware In-Reply-To: References: <54039A45.8020804@wb4gcs.org> Message-ID: <5403CA07.2010802@wb4gcs.org> That did it, thanks!!!!! 73, Jim wb4gcs at amsat.org On 8/31/2014 9:15 PM, Dave Larsen wrote: > Jim > > Almost right > > There are two programs, HPSDRProgrammer V2 only talks to boards with > ethernet sockets and does not need the j1 jumper but it will not > program through a JTAG port. > > the second program HPSDRBootloader is for use in the Bootloader mode > as you specified. If you follow your steps, EXCEPT use > HPSDRBootloader it should work.. > > HPSDRBootloader uses the pcap library, the J1 jumper and a raw > Ethernet packets and cane be used as a JTAG programmer for boards with > no Ethernet connector. > > HPSDRProgrammer V2 is use UDP, no jumper and old firmware newer that > 2.3, This is convenients for update firmware without opening the box. > But if the old firmware is broke it will not work. > > > PS. HPSDRProgrammer V1.6 does both tasks but people got confused > different problem and what part of the program when with each task. > > Dave KV0S HPSDRProgrammer V2 and HPSDRBootloader Programmer and > Maintainer > > > On Sun, Aug 31, 2014 at 4:57 PM, Jim Sanford > wrote: > > ***** High Performance Software Defined Radio Discussion List ***** > > All: > I am finally assembling the system I purchased in pieces long ago > from TAPR. > > I have successfully updated Metis firmware to the latest. > > I have installed J1 in Metis to put it in bootloader mode. > > I have installed J7 (last JTAG) jumper on Mercury. > > Running HPSDRProgrammer V2 version 2.0.4.0 > > All the LEDs on Mercury that the manual says should be lit are. > > When I click DISCOVER, Mercury is not found, and I get an error > message telling me to "Make sure the correct interface is > attached. There is only one interface -- the ethernet interface on > the computer. > > Any suggestions?? > > Thanks & 73, > Jim > wb4gcs at amsat.org > > > --- > This email is free from viruses and malware because avast! > Antivirus protection is active. > http://www.avast.com > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: > http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ > > > > > -- > KV0S - Dave Larsen > Columbia, MO, USA --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From beford at myfairpoint.net Sun Aug 31 18:41:29 2014 From: beford at myfairpoint.net (Bruce Beford) Date: Sun, 31 Aug 2014 21:41:29 -0400 Subject: [hpsdr] SOLD Munin amp kits for sale Message-ID: Both Munin amps kits have been spoken for, pending funds. Thanks for all the replies. Bruce N1RX -------------- next part -------------- An HTML attachment was scrubbed... URL: From getpri at t-online.de Sun Aug 31 23:24:58 2014 From: getpri at t-online.de (georg Prinz) Date: Mon, 01 Sep 2014 08:24:58 +0200 Subject: [hpsdr] KISS Konsole on Ubuntu 14.04 In-Reply-To: References: Message-ID: <5404113A.1000700@t-online.de> Hello Jae, wow, good to hear that you were successful so fast. I am interested in your experience to port everything into Ubuntu. I updated my system to Ubuntu 14.04 last week, but I am not very happy with my system as it seems to have some problems. I guess I have to start with a new OS from a CD instead of upgrading. As I am running a dual boot (win7/ubuntu) OS, it is always a problem loading one system from scratch, only. So, I am just in front of starting with HPSDR on linux and eager to get informations about all the pitfalls. 73, Georg DL2KP Am 31.08.2014 22:30, schrieb Jae Stutzman: > ***** High Performance Software Defined Radio Discussion List ***** > > > > After about 3 hours worth of work and a few workarounds, I made my > first QSO on 20 meters under Linux! > > I used MonoDevelop as the IDE for the C# KISS solution. I had to make > a couple of changes for the P/Invokes of the fftw3f library and some > of the Networking calls, which are still not implemented within the > Mono CLR. The performance is quite good, I'll compare it to my Windows > box to see the differences. > > Here is a link to a screenshot of how it looks: > http://imgur.com/AsJ4pSE. I'll document my changes and the > dependencies that I installed to make it work soon. > > Thanks everyone for the welcome and thanks to the authors of KISS > Konsole for making the porting easy :) > > > 73, > > Jae - K5JAE > > > > > > _______________________________________________ > HPSDR Discussion List > To post msg: hpsdr at openhpsdr.org > Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org > HPSDR web page: http://openhpsdr.org > Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ -- Internet: in progress ********************************************************************** IMPORTANTE/IMPORTANT CONFIDENCIAL/CONFIDENTIALITY Este mensaje ha sido elaborado ?nicamente para uso de la persona o entidad a la que es remitido, ya que puede contener informaci?n personal, confidencial y de acuerdo a ley no puede ser difundido. Si el lector de este mensaje no es el destinatario se?alado, o la persona responsable para entregar el mensaje a quien est? dirigido, advertimos que cualquier divulgaci?n, retransmisi?n o copia de esta comunicaci?n esta estrictamente prohibida. Si usted ha recibido esta comunicaci?n por error, por favor s?rvase informarlo de inmediato al remitente por correo electr?nico o tel?fono y borrar inmediatamente el mensaje original. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail kann vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ********************************************************************** --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: