- PSDR - mailman.hamwan.org

Signal processing challenge
by Bart Kus 10 May '14

10 May '14

Hello, Do you like software defined radios? Do you like digital communications? Me too! I took a Ubiquiti XR3 radio modem configured to operate in NV2 mode with 20MHz bandwidth centered at 3.65GHz, and mixed it with a 3.68GHz local oscillator. The resulting unfiltered mess got fed to my oscilloscope which digitized it into the attached file. The sampling rate was 250MSa/s and the capture length was 32768 samples. The data in the file represents a single NV2 beacon transmission, which lasts about 84us. The captured signal should be centered at 30MHz with a 20MHz bandwidth. Having looked at the signal in the frequency domain before digitizing it in the time domain, I can tell you there are some unwanted mixing products here along with the desired signal: Main Signal The above image shows a marker (X) on the main signal at ~30MHz. Product 1 The above image shows a marker (X) at one mixing product at ~1.68GHz. Product 2 The above image shows a marker (X) at another mixing product at ~2.0GHz. Can you extract the data from this beacon frame? The outermost encoding should be 20MHz 802.11a OFDM. --Bart

1 0

HamWAN over tideflats
by Tom Hayward 08 May '14

08 May '14

Last weekend I had the chance to play with my HamWAN portable setup (this is the Poynting dish, RouterBoard Metal 5SHPn, 11.1V battery, and tripod combo you see on http://hamwan.org/ homepage). I set up at the Camano Island survey location shown on the map. It's right at water level with a clear view toward Everett. When I first set up, I got a signal level of about -58 dBm. Wow! This is great for 21 miles at 5.9 GHz. As the tide went out, I saw the signal dip to around -76 dBm. This was over about 250 yards of mudflats. As the tide came back in, I saw the signal climb until the water reached the bulkhead (about 5 ft from antenna), and the signal level hit -54 dBm. The computer model predicts a path loss of 145 dB, which would put my signal level at -71 dBm. You can see from the numbers that the water improves the signal level. This was not predicted. What causes it? Kenny linked me to an interesting paper on the topic, although my observations differed from theirs: http://www.researchgate.net/publication/224138836_Slow_Frequency_Hopping_fo… I find the effect of tides on signal level very intriguing. This is the sort of effect that makes 5.9 GHz microwave interesting to me. Tom KD7LXL

7 11

Capitol Park Sectors 2 and 3 Now Available
by Nigel Vander Houwen 06 May '14

06 May '14

Hello All! Thanks to the work the install team did onsite last week, and the work of our network admins, sectors 2 and 3 at our Capitol Park site should be ready for connections. This brings Capitol park to having the full coverage of sectors. Please let us know of either any reports of success, or issues with getting connected and we'll be glad to hear/help out. The improvements made over the last few days including the visit to the site are a big win for the network, and we are pleased to continue the work to expand coverage and continue improving the network. Thanks, Nigel K7NVH

1 0

Request for Software - IP Protocol Filtering Measurement
by Bart Kus 05 May '14

05 May '14

Hi, During some cell site work last night, I seem to have experienced Comcast dropping packets from point A to point B simply based on the fact that their IP protocol was GRE (IP protocol 47). I also found some posts on the Internet that claim Comcast wishes to charge more money to transport GRE packets. I'm not sure if this is true, or if I made a mistake somehow in my traffic handling. Therefore... Would someone be willing to create software instruments to measure this claim in general? I'd like to see a transmitter and a receiver piece of software that can run on Linux to generate and record a sweep of IP packets carrying all possible protocol numbers (0-255). The protocol payloads themselves don't need to be well-formatted, just the protocol number in the IP header needs to be set. Your software will be considered successful if it measures 100% of all protocols as available over an unfiltered (eg: LAN) link. The results of such a measurement would be useful in gauging the ISP quality of any given carrier. It seems we're moving closer to Selective Protocol Service Providers (SPSP) and away from true Internet Service Providers (ISP) if this GRE finding turns out to be right. --Bart

5 5

VOTE: $2k budget for Haystack site hardware
by Bart Kus 05 May '14

05 May '14

Hello, I'd like to propose we allow spending of up to $2k to cover the costs of installing a photovoltaic (solar) power system @ Haystack. The site owner has allowed us to host a site up there as long as it doesn't impact their power budget. The site is not wired to any utility power, and transporting propane to it is expensive. This is a 1-time cost, and the hardware will remain property of the site owner. In exchange they'll be giving us new mounting points for 2 dishes and 2 sectors, which will have a huge impact on coverage and extending the network. Our recurring cost for the site will be $0/mo, which is an ideal long-term arrangement. Here is a list of the hardware required: Costs converting 12VDC to 24VDC Item Desc Link Quantity Cost Total 1 24->12VDC MeanwellSD-50B-12 http://www.mouser.com/ProductDetail/Mean-Well/SD-50B-12/?qs=jVZN1Oke4Bx6867… 1 $51 $51 2 SolarWorld 275 Watt Mono Module http://www.backwoodssolar.com/solarworld-270-watt-mono-module-1359 2 $347 $694 3 30' Cable with Locking MC4 Plugs http://www.backwoodssolar.com/30-cable-w-locking-mc4-plugs 2 $30 $60 4 Midnite AC Din Rail Mount Breaker - 15A & 20A (15A is needed) http://www.backwoodssolar.com/outback-60a-ac-breaker 2 $19 $38 5 Fuse Holder and TWO 60A Class R Fuses http://www.backwoodssolar.com/holder-for-100-amp-fuse 1 $28 $28 6 PV Module Ground Lug/screw/nut http://www.backwoodssolar.com/pv-module-ground-lug-screw-nut 2 $4 $8 7 Battery Interconnect Cable - 24" - 4/0 http://www.backwoodssolar.com/products/batteries-accessories/battery-cables… 10 $26 $260 7a Battery Interconnect Cable - 24" - 2/0 Local -> Pacific Power Battery (+$5/end to crimp) 10 $10 $100 8 IOTA Battery Charger - 24V 40A - DLS27-40 http://www.backwoodssolar.com/iota-40a-24v-battery-charger 1 $395 $395 9 Tax (.086) Sultan Mailing Address http://dor.wa.gov/docs/forms/excstx/locsalusetx/localslsuseflyer_quarterly.… 1 $78 $78.24 10 5% for cables/time/mounting etc http://3.bp.blogspot.com/-yJZJIOW6lys/Twvf9ylPUGI/AAAAAAAACdk/YEUZm-ZR-QU/s… 1 $45 $45.49 Grand Total $1,757 In the $2k request, I'm also allowing ~$250 for shipping costs. Solar panels are large. Anything not spent will be returned to the HamWAN budget. We already have all the other hardware required to deploy the site in-stock. Some of it is already deployed (Haystack-S3), and some is sitting on-site (modems, 1 dish, other sector). Our present balance is $1,291.04, so we'd be going into debt for this deal. The other cost of this deal is recognizing the site owner's sponsorship of HamWAN by including their logo in presentations, and offering some man-hours for site maintenance. The big project this summer (aside from this solar system install and the full HamWAN site install) will be helping with installing a grounding system there. My vote on this deal is: YAY. --Bart

8 9

ToorCamp / RF Palace
by Bart Kus 05 May '14

05 May '14

Hi, Can I get a roll-call of everyone going to toorcamp this year? Also, are we doing RF Palace again this year? My talk was just accepted there for this summer, and they're asking if I'm still into doing a microwave field demo. I was planning to setup an interactive demo of 6GHz that people can walk though, interact with, reflect, absorb, etc and get audio feedback on their actions. However, to get that running we'd need to have an official camp site going with people helping to supervise the gear since it's quite expensive. If we're not doing the RF Palace this year, I don't wanna bring any microwave gear. Let me know, --Bart

3 2

Metal 5SHPn firmware 6.12 is current (addendum)
by Dean Gibson AE7Q 04 May '14

04 May '14

Note also: What's new in 6.11 (2014-Mar-20 09:16): *) ... *) ovpn - make bridge mode work with big packets (do not leave extraneous padding); Is this related to the "change-mss" firewall mangling rules in our own setup?

6 9

Metal 5SHPn firmware 6.12 is current
by Dean Gibson AE7Q 03 May '14

03 May '14

Changelog. Note the first item. I've installed it. With permission, I'll change the link on the HamWAM client config page. What's new in 6.12 (2014-Apr-14 09:27): *) l2tp - fixed "no buffer space available" problem; *) ipsec - support IPv4 over IPv6 and vice versa; *) pppoe - report correctly number of active links; *) updated timezone information; *) many fixes for CRS managed switch functionality - particularly improved VLAN support, port isolation, defaults; *) added trunk support for CRS switches; *) added policing support for CRS switches; *) www - added support for HTTP byte ranges; *) lte - provide signal strength using snmp and make 'info once' work in console; What's new in 6.11 (2014-Mar-20 09:16): *) ipsec - fix aes-cbc hardware acceleration on CCR with key sizes 192 and 256; *) wireless - add auto frequency feature; *) ovpn - fixed TLS renegotiation; *) ovpn - make bridge mode work with big packets (do not leave extraneous padding); *) ovpn - fixed require-client-certifcate; *) ppp - revert RADIUS NAS-Port behaviour, report tunnel interface id; *) ppp - mppe encryption together with mrru locked the router; *) dhcp - added support for DHCP option 138 - list of CAPWAP IPv4 servers; *) quickset - added Guest Network setup to Home AP mode; *) console - no longer required to supply value of '/routing bgp instance vrf' property 'instance' for 'add' command; *) ethernet - added option to enable rx/tx flow control (will be disabled by default); *) ethernet - added ability to specify advertised modes for copper ports; *) fixed 100% cpu usage on CCRs; *) ssl - not finding CRL in local store for any certificate in trust chain will cause connection to fail; *) lte - support for Huawei ME609 and ME909u-521;

1 0

An insanely great improvement in signal strength between Baldi and Capitol Park
by Bart Kus 03 May '14

03 May '14

Dish alignment is a really important thing. :) -82dBm is now -52dBm. All glory to the site crew who did this, and other great work yesterday: NQ1E (Cory), Nigel (K7NVH), Tom (KD7LXL), and David (KB7ILD). --Bart

3 3

44.x.x.x HamWAN network at Paine
by Dean Gibson AE7Q 01 May '14

01 May '14

I have an idea to provide additional radio network connectivity to the Snohomish County DEM at Paine on 23cm, that would require one or two fixed 44.x.x.x IP addresses at the DEM, and one at my house (separate from my MikroTik radio), that would be accessible via the present 44.24.240.x connection to Paine (and perhaps any other 44.24.240.0/20 address). Both involve the use of two (or more) Icom ID-1 radios in D-Star DD mode. Background: An Icom ID-1 in DD mode acts just like a piece of Ethernet cable (except that it is half-duplex and limited to a raw 128Kbps speed). No IP address is (or can be) assigned to the device. Any Ethernet packet reaching the ID-1's Ethernet port (whatever the content) is simply encapsulated and transmitted if the radio is in DD-mode. Similarly, any received data (properly encapsulated by another ID-1) is simply sent out the receiving radio's Ethernet port. The only radio configuration possible is to select a 23cm frequency and set the radio into DD-mode. Most of these actions can either be done by the radio's control head, or via a USB port "connected" to a Windows PC running Icom's control software for the ID-1. This prior sentence is important in the following discussion. As an aside, the transmission of an ID-1 can be addressed to and received by a D-Star DD-mode "repeater" module, routed via the D-Star network over the Internet to another such "repeater" module anywhere in the world, and retransmitted over the air to a receiving ID-1 radio. This mechanism, while perhaps interesting, is not the subject of this eMail. I only mention it so as to avoid confusion. In scenario #1 for the ID-1 that already is installed at the Snohomish County DEM: 1. The Ethernet port of the ID-1 is directly connected to a switch at the DEM that is on the 44.24.240.x network. In this mode, any packets received over-the-air by the ID-1 are injected into the local 44.24.240.x network, and are routed in exactly the same manner as from any other device hard-wired to the 44.24.240.x network at the DEM. Further, any Ethernet packets seen by the ID-1 (whether intended for radio transmission or not), would be transmitted by the ID-1. 2. Another ID-1, located (say) at my house would be connected to a router, which would act as though it were directly connected to the 44.24.240.x network at the DEM. I don't view the above scenario as a good idea. For one thing, the indiscriminate transmissions from the DEM of unrelated 44.x.x.x packets doesn't seem like a good idea. For another, there is no security. So, that brings me to scenario #2: 1. At the Snohomish County DEM, place a router (or bridge) between the ID-1 and the 44.24.240.x network. 2. In this scenario, the ID-1 located at my house would also be connected to a router that acts as though it were directly connected to the 44.24.240.x (or any other) network at the DEM. Now, here is the wrinkle (to both scenarios): The ID-1 at the DEM is currently in VERY LOW utilization, being (as so far as we know) only able to contact my ID-1 (in either digital data or voice mode), and the two 23cm D-Star K7LWH repeater modules (one voice, and presumably one data) in Bellevue. Also, the ID-1 also supports normal FM voice mode, and is easily able to hit with one watt (from both the DEM and my house) the KB7CNN 23cm FM repeater on East Tiger Mountain. So, it would be nice to use the DEM's ID-1 radio in different modes, as needed, and switch modes or frequencies REMOTELY as desired. The solution to this the use of a Digi "Anywhere/5" (or "/2") Ethernet-to-USB box (I have several). With the installation of Digi drivers on any Windows PC, these allow a PC anywhere in the world to connect over the Internet to a Digi box and have access to several remote USB devices (including any connected USB hubs). In particular, the USB control port of an ID-1. In fact, this is how I control my ID-1 at home: this allows me to control the ID-1 from any Windows PC. Hence the desire for a fixed 44.24.240.x IP address for the Digi box at the DEM, allowing REMOTE control and configuration of the ID-1 when the Internet is not available. While the Digi box can be connected to any network at the DEM, it seems most productive to connect it to the 44.24.240.x network there, allowing remote configuration and control of the ID-1 in an Internet outage (this can be disabled by unplugging the ID-1's USB port). Unfortunately, the Digi USB boxes are only usable from Windows systems (Digi's remote SERIAL (RS-232) port boxes are supported not only on Windows from 98 on, but on most variants of Linux ...). Yes, this provides a much slower connection to the DEM than the MikroTik radios, but doesn't have quite the strict line-of-sight issues that 5cm does, and thus permits some mobile access. To Scott Hokaker: I am willing to provide a Digi "Anywhere/5" box on permanent loan (or perhaps donation) to this project. I also have a couple of consumer-grade routers (Linksys BEFSR41, Netgear WGT624v2) that are similarly available, if they are suitable. Comments welcome! -- Dean

10 20