44net

44net@mailman.ampr.org

3170 discussions

Re: [44net] Outdated regulations [Was: OFDM Modem]

by Steve L

Well we just heard a few days ago that some foreign hams don't have a bandwidth restriction, other than it fits in the band. I haven't heard of any ill effects from over there, but maybe someone from abroad can chime in. I can see it being a concern on HF, where the spectrum is more limited, but I am pretty much with Brain for above 50 MHz. Further more is takes a least a dozen years to make any headway with the FCC, so I highly recommend futuristic thinking when writing comments. Bruce Perens recommended basically do away with the bandwidth limits, and let gentlemans agreements take rule. I think that seems logical. Especially when the alternative is a 10-15 year re-revising the rule, piece meal approach game like we have been playing, that really just impedes innovation. But no one has to agree with me. You just have to file comments to make me happy :-) Further more, I see like less that 5% of the ham population being actually capable of sending a 2 MHz wide signal, so the point is pretty much moot (Everyone else has a Beofeng HT.) >Now imagine someone sending a signal 2 mhz wide on 447 mhz not really cool for the rest of the >Ham community. That is why we need band with limitation

7 years, 4 months

Re: [44net] OFDM Modem

by Rob Janssen

> A couple of decades ago, the "GRAPES" WA4DSY 56kbit modem kit was > available for a moderate price. They weren't too difficult to put > together. Alignment did take a scope, but took only a few minutes. About > five people in San Diego had them. As far as I know, only three ever > made it onto the air here. I remember that modem, but also I remember that there were quite some issues at that time. It was not easy to reliably make 56k HDLC using affordable hardware at that time. For interrupt-per-character serial devices the performance of a PC-XT was not quite enough. There were DMA-based controllers but they were difficult to obtain, hard to find reliable drivers for, and expensive. Some people built 68000-based boards for that kind of datarate, and later for 1-2Mbps, also using DMA. I also considered using PC-LANA adapters that had all the data generating hw as a co-processor but were not AX.25 compatible. (they use the NETBIOS interface, I added IP over NETBIOS to my version of NET to be able to use them) However, no real radio link has ever been made here. Of course wide acceptation would have been even more difficult. Today, the computer performance problem no longer exists, but the problem of wide deployment of a locally designed solution still exists. Rob

7 years, 4 months

Re: [44net] Outdated regulations

by Steve L

In an online conversation with Brian N1URO, we have both come to the same conclusion: We need a group such as TAPR to start getting more involved with the FCC and bypass the ARRL. I remember back when I never really understood TAPR. I knew what the name stood for, so I always assumed they were the voice representing the digital aspects of the hobby. Then I heard a 2008 Rain report where Steve Bible explained TAPR. http://kb9mwr.blogspot.com/2009/02/tapr-explained.html I wonder if there is any chance of them taking up the role that I thought there were about? And as I stressed before, I feel its important to have a futuristic thought process when making comments as it takes many years for regulator changes to actually happen. And in that light, this is from a 2012 webinar, where Chris Imlay W3KD and Ed Hare W1RFI predict and speculate what ham radio will be like in 25 years (2037): http://kb9mwr.blogspot.com/2013/09/amateur-radio-in-2037.html Listen to that when you have the time, add your own thinking and start drafting your thoughts to the commission. Steve

7 years, 4 months

Re: [44net] OFDM Modem

by Rob Janssen

Very interesting indeed! You are probably aware that there is some activity on Digital ATV and the boards made for that purpose (and/or the cheap dongles they use) could be used for this as well. We have a Digital ATV repeater here that is currently under some reconstruction, and I have suggested putting some IP broadcast on the multiplex. Indeed, as you note, a Linux-based DVB receiver can easily put the demodulated and extracted IP traffic on its LAN interface. More than a decade ago I did some "experiment" logging the downlink of satellite-internet on a Dreambox and it just used standard features of its software. But your test of using this full-duplex (rather than just unidirectional as it was envisioned) surely is innovative. It could be useful here as well, indeed as you indicate to make links on amateur bands for which there is no commercial WiFi equipment. It is not straightforward to use that equipment with transverters, and a steady fullduplex link would certainly be easier. Some people are also working on a 70cm digital access with smaller bandwidth, there is little detail on what modulation they use, it would be interesting to see if using DVB-T2 in halfduplex more is feasible. Probably not, due to high turnaround delays. Rob

7 years, 4 months

Re: [44net] Outdated regulations

by Steve L

My bad, I sent this again to the 44net list in error. To many mailing lists! Sorry guys..

7 years, 4 months

Outdated regulations

by Steve L

I just spotted this. Here is every US hams chance to make direct comments to the FCC. http://www.arrl.org/news/fcc-technological-advisory-council-investigating-t… Here are some issues that I have been hammering the league on for quite some time; but really its time for everyone to review the Part 97 rules and write comments directly to the FCC. http://www.qsl.net/kb9mwr/projects/wireless/70cm-ATV-HSMM.html Steve, KB9MWR

7 years, 4 months

Re: [44net] Outdated regulations [Was: OFDM Modem]

by Steve L

Michael, The elimination of symbol-rate restrictions has already been proposed since 2013. That would still leave a 100 KHz data restriction for UHF (70cm), and some how that seems unfair when Image modes (ATV) have no restrictions and typically have a 6 MHz wide signal. Bruce Perens had some good ideas a few years back in https://ecfsapi.fcc.gov/file/7022090358.pdf A lot of it was related to codec2, but its all time for us to put on our thinking caps and write comments to the commission. I hope to see some familiar names in the coming days. http://www.qsl.net/kb9mwr/projects/wireless/70cm-ATV-HSMM.html

7 years, 4 months

Re: [44net] An anniversary of a sort - 36 years

by Steve L

Packet radio was a big lure to me when I was in high school in the 1990's. The mainstream internet hadn't yet blossomed, and I was always looking to tap into information networks (voice and data) so I could learn and build stuff. At the same time I read an article by Larry Kollar, KC4WZK on the Amateur Packet Radio Network that was floating around on dial-up BBS's and really caught my attention. One of my Elmer's gave me a pile of NE2000 coax LAN ethernet cards. That combined with watching the trace screen on the various NOS programs really helped my learn how it worked. So I was a young person back then, I can say it helped me immensely understand how the internet works. And I am still learning. (As that is what ham radio is to me). A few years back my internet provider started handing out IPV6 addresses. So on my personal network I started to implement dual stack. And then wondered what good this really does as you are still using a V4 address for the sites you connect to that don't yet support ipv6. Not like you are saving an IPv4 address. Then I learned the next phase would be carrier grade NAT. Fortunately or unfortunately (depending on how you look at it), we are not to that point yet where I live. But you can experiment with the Google NAT64 gateway etc. Since I have some legacy ipv4 radios., I wouldn't mind trying to run my own NAT64 gateway on Linux. But I haven't gotten that far yet. And the documentation out there is a bit foreign to me yet. Another thing I have been meaning to try and do is some sort of 10.x.x.x to 44.x.x.x. 1 to 1 NAT thing for the folks doing Broadband Hamnet/AREDN.

7 years, 4 months

OT: Confirmed issue: AX.25 binaries failing to run on Raspbian Stretch with predictable network interface names

by David Ranch

Hello Everyone, I'm currently working Thomas Osterried and Ralf Baechle on this below issue but I thought I'd email this out to the list just in case you hit it. Both Thomas and Ralf have confirmed it and the root issue is the length of the Ethernet interface name which is due to Stretch's new default of using predictable network interface names. Below mentions how to revert back to the classic "eth0" interface naming convention which will get things working again. --David KI6ZHD While running Linpac on the console (not over SSH) on Raspbian Stretch, I would still see errors like "SIOCGIFHWADDR: No such device" but the program wouldn't crash. If I would run Linpac over an SSH terminal, it would crash. I then was comparing straces of linpac running on the console run linpac vs. the ssh run linpac and was gravitating towards various locale issues and trying different environment variables like LANG, LANGUAGE, TERM, etc but nothing was getting me the consistency of *not* crashing when using an SSH terminal. I was then noticing that in the SSH-based sessions of running Linpac, it was constantly coming back to the Raspbery Pi 3's Ethernet interface which is named "enxb827eb5f053b" in Stretch but it's "eth0" in Jessie. -- root@rpi3:/etc/ax25# ifconfig ax0: flags=67<UP,BROADCAST,RUNNING> mtu 253 ax25 KI6ZHD-6 txqueuelen 10 (AMPR AX.25) RX packets 68 bytes 5306 (5.1 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 5 bytes 20 (20.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 enxb827eb5f053b: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.24 netmask 255.255.255.0 broadcast 192.168.0.255 ether b8:27:eb:5f:05:3b txqueuelen 1000 (Ethernet) RX packets 735 bytes 55331 (54.0 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 559 bytes 109673 (107.1 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 1 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether b8:27:eb:0a:50:6e txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 -- I've never personally been a fan of the new predictable network interface names but I've dealt with them. On a lark, I disabled the predictable naming convention and brought back the classic eth0 name per making the following change in the /boot/cmdline.txt file: https://serverfault.com/questions/741210/disabling-predictable-network-inte… With that in place.. No more crashes! Man.. that's VERY surprising to me but now that I'm paying very close attention, I'm seeing the same issues in the standard AX.25 programs! When I start the "axbeacon" program with no interface specified (that means it will listen on all AX25 interfaces), I'm seeing: strace -f /usr/bin/listen -artc 2> /tmp/beacon.strace root@rpi3:/etc/ax25# echo $? 22 I've attached that strace as well and it also has signs of persistent Ethernet naming issues (notice below that the full interface name is missing the "3b" at the end of the Ethernet interface name"): -- ioctl(3, SIOCGIFHWADDR, {ifr_name="enxb827eb5f05"}) = -1 ENODEV (No such device) dup(2) = 5 fcntl64(5, F_GETFL) = 0x20001 (flags O_WRONLY|O_LARGEFILE) close(5) = 0 write(2, "SIOCGIFHWADDR: No such device\n", 30SIOCGIFHWADDR: No such device -- I have confirmed this happens with both the 3rd party VE7FET's AX.25 sources ( https://github.com/ve7fet/linuxax25 ) and the standard .deb packages repos supporting Raspbian Stretch. It seems there is an even bigger issue for the Debian .debs as it's axlisten wasn't properly compiled with Ncurses support as it gives the addition error: -- Could not initialize color support. -- At least the beacon program doesn't crash like LInpac but all this confirms there is something wrong here that something just with Linpac. --David KI6ZHD

7 years, 4 months

Re: [44net] An anniversary of a sort - 36 years

by Steve L

Well if you look back to the much earlier days a lot of good things came from the allocation. Most of it was the work of Phil Karn and a few others. And maybe it would be good to document that stuff, as most of it was before my time. I know Phil and Brian Kantor were active with the development of RFC's. This contribution was was something that extends beyond ham radio. Phil's NOS development really changed a lot of things. Lead to some FCC rules being changed etc. Again, I am not the person with all the history, but just wanted to make a few brief points. I do hear you though, now-a-days, ham radio in general is in a pretty sad state. You could easily replace the words "our /8 network is of great value these days" with our allocated frequencies are of great value these days. I do agree we really need to reach out to the hacker/makerspace people. I wrote this a number of years ago for our club: http://www.k9eam.org/2011/06/innovating-makerspaces.html There have been a small handful of us that attend their meeting and help them with things. A few got licensed, but so far no one has really dug in deep into the radio side yet. At least the goodwill has been established. Like anything in the hobby and world in general, it takes the right(ambitious) people to make amazing things happen. Steve > What *new* technologies has been developed because of this network? > Which crises have been mitigated using this network? Have it helped to > spread the HAM radio "spirit" to the young people? What other good > things have this network done?

7 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net