44922035

Members
  • Content count

    8
  • Joined

  • Last visited

Community Reputation

0 Neutral

About 44922035

  • Rank
    Will I break 10 posts?

Contact Methods

  • Website URL
    http://
  • ICQ
    0
  1. I think you're going to have a couple different problems. Take the internet delayed link out of the picture and you still need to zero beat the four transmitters. For some ideas see: http://www.k7pp.com/art006.html If you inject some sort of possibly subaudible syn tone say at a specified interval on the originating feed, you might be able to decode that at each site and re-clock the whole thing thru some sort of audio delay system.
  2. Does anyone have this letter, or know what issue that might have been in? I'd be curious to read more on the lines of software frequency adjustment if anyone knows anything else.
  3. I can't disagree. I'm not even sure of the status of the mirrorshades router anymore. I'd tend to think Brian Kantor is close to retirement from UCSD. The main problem is; gone are the days of passing 44 traffic over the internet, or where IPIP was a protocol that saw little hinderance. Alot of internet service providers and (from what I understand) alot of router equipment by default now blocks this type of traffic. More accurately, many internet service providers block outgoing traffic originating from within their network IF the ip address is not from within their own allocation of numbers - meaning that IP packets having a source address of 44 will never make it out. I know Maiko Langelaar, proposed and wrote a IPUDP encapulation routine, but I'm not sure the UCSD mirrorshades router has provisions for this. So that sort of leaves the 44/8 as another un-routabe domain. I remember messing with automated ways to update route tables over radio paths, as manual updates were always a hassle. But at 1200 or 9600 baud, BPG isn't to cool, or for that matter even cached DNS. If nothing else, perhaps the option of having ampr.org work as a dynamic dns for hams could be usefull. Right now the cache time & method to update the hostname to bind to your public IP isn't very user friendly.
  4. I remember reading an article about packet radio in Phrack, and I think that's what prompted me to get my ticket in 1996, when I was in high school. Linux was just starting off then, fortunatly Phil Karn had wrote a TCP/IP stack software for MS-DOS in the 80's, and this TSR (terminate and stay resident) application allowed support for the TCP/IP traffic, and command line utilities to handle ping, ftp transfers, and more. As many know, later down the road as Linux gained momentum it had built in AX.25 protocol support In the late 1970's Hank Magnuski, (while AX.25 was just a dream - for that matter TCP/IP was still being developed by a group headed by Vinton Cerf.) he had a vision to be able to use TCP/IP in ham radio applications, he reserved a Class A IP address block AMPRNET 44.0.0.0 for ham radio. Some where in the 80's AMPRnet was born. It provided a way to connect the disjointed ham radio TCP/IP networks together. It would piggy-backs over the internet very much like a VPN (Virtual Private Network), using IPIP encapsulation. It was a project worked out with the University of California, San Diego to route and provide DNS services for this amateur IP address block. Where I live, we had a series of TheNet or X1J packet nodes throughout the state. Thenet custom EPROMS allowed packet nodes the added functionailty to route TCP/IP as well as AX.25. Each city had it's own subnet, and a 9600 backbone to each. There were a couple packet gateways. There was/is an email robot for coordinators to setup ampr hostnames and assign NET-44 IP addresses. Another robot alllowed a gateway owner to specify its Internet address and the ampr subnets that it services. We could ping/telnet/sendmail (over radio) to subnets states away. In my case, my ping would route to the local centrally located 9k6 TheNetX1J node that knew my packet needed to go over another 9k6 channel reach the guy running the gateway a city away. Once it got there the my Net44 address was encapsulated and sent the the mirrorshades ucsd.edu amprnet router. It analyzed and further routed the packet to the appropriate gateway a couple states away. That gateway would sent it back over radio though various radio X1J routing nodes to the destination station. It was pretty cool all things considered. Then of course the public internet caught on, and the speeds of telephone modems advanced faster than the ham radio speeds could.
  5. I've used Asterisk over WiFi. I've also used IRLP over WiFi. (By the way there is a Desktop mode that can take IRLP off the network and lets you use the native SpeakFreely to talk to it in a private network peer to peer type of way). You could use a WiFi phone or configure a DingoTel tway radio adaptor to talk over a WiFi connection. I never thought about use a WiFi phone in stuck traffic like a CB... interesting thought, even more-so with the hot babe situation :-) Asterisk over Wifi has a lot of possibilities. You can configure extensions to play podcasts on the fly, or your own virtual digital radio station, like XM.... Granted the audio isn't perfect for that, but you could mess with the codecs.
  6. Years back I questioned how difficult it would be to alter the frequency slighty. I'm sure you are aware with the newer Atheros chipsets, and are many additional channels that can be unlocked. The Atheros chipset doesn't really know about channels; they are determined by the code that's loaded into it at boot time. All of these country codes (including XX or ## which have been used for "without regulatory constraints") are part of the driver, or "hardware abstraction layer" (HAL). Atheros will sell you the tools to build a driver, if you're manufacturing a device and do a licensing agreement with them. There is a partially open source driver for Atheros chips at madwifi.org ... but (per agreement with Atheros) the HAL is a locked-down binary that restricts you to the Part 15 channels. There is another company, Ascom in Switzerland (www.ascom.com), that has written their own Atheros driver (under Atheros license), and will provide various versions of it for a fee. I believe that this is the source of the implementations out there that permit operation out of the ISM/UNII bands such as Mikrotik, StarOS, Ikarus. There is probably a lot that can be learned about hacking the madwifi driver. If getting down to the HAL or building your own driver is a bit beyond some of you, StarOS software by Valemount Networks does unlock many additional features of the Atheros Chipset . One of these settings is the country code. Which unlocks these 2GHz IEEE 802.11b/g channels (frequencies are given in MHz): 2312, 2317, 2322, 2327, 2332, 2337, 2342, 2347, 2352, 2357, 2362, 2367, 2372, 2412, 2417, 2422, 2427, 2432, 2437, 2442, 2447, 2452, 2457, 2462, 2467, 2472, 2484, 2512, 2532, 2552, 2572, 2592, 2612, 2632, 2652, 2672, 2692, 2712, 2732
  7. I ran into an interesting licensing scheme recommendation at : http://www.ntms.org/802.11/ARRL%20Board%20...tors%202005.doc Here is a partial excerpt: Improving and Expanding Amateur Radio in the 21st Century 50 years ago, amateur radio service gave its licensees access to wireless voice communication services that were otherwise unobtainable and trained people for careers in industry. It should be doing the same for today's wireless communication but isn't. This is a proposal for a 21st century novice license oriented towards HSMM. It would change amateur radio somewhat, but would ensure its existence by attracting younger users and make it more relevant to today's technology. First, let me explain why new novice licenses are needed. The current Amateur radio licensing system assumes that everyone wants HF access and they proceed along an upgrade path to get it. License classes are hierarchical. However, there are several groups of users within the ARRL that have different interests. Some are interested in having the best HF station and contesting or chasing DX. Others are interested in weak signal communication using portable stations on the microwave bands. One large group is interested in personal communication and emergency communications with VHF and UHF repeaters. Another group is interested in digital communication using computers. The "one size fits all" arrangement does not serve any group well and creates unnecessary contention among groups. If license classes were organized by area of interest and new hams just picked the licenses that fit their needs, each license could better fit the interests of each ham. Rather than acting as an unnecessary impediment that is shrinking the ranks of the hobby, licenses could encourage new growth. Licensing that fits user needs could be more restrictive for HF spectrum where the number of users that can be supported is small and become less restrictive as the frequencies go up and large numbers of users can be accommodated. Many amateur HF users prefer the traditional form of FCC regulation with highly structured bands and a Morse code requirement for their portion of the spectrum. The existing license structure largely fits their needs. However, hams interested in buying HTs and using voice repeaters face a lot of examination requirements that are unnecessary for their purpose. They should have a simpler license where they learn how to set up a limited station and agree to certain operating procedures and frequency ranges. This would encourage new membership and build the pool of emergency communicators. Hams who want to set up repeaters or do high-power weak-signal communication on the VHF and UHF bands require more knowledge as they will be setting up larger, more complex stations. The current license examination system with an exam that stresses design requirements and RF safety fits these needs. However, a new license class for HT users would benefit the radio clubs setting up and maintaining repeaters by providing more members. Those interested in computers and digital communication are under-represented in amateur radio ranks. They are technophiles as we are, but the current system does not serve them well. This is disturbing, as digital communication is the future. In particular, amateur radio should encourage the participation of those interested in software as all electronic communication now depends upon it. There should be a license class where they agree to certain frequency ranges and non-interference provisions. This type of license would expand the use of new technology, make the learning experience of amateur radio more relevant to ham's personal lives, increase the use of our microwave bands and allow the development of and experimentation with new high-speed multi-media applications. It also assists us in supporting public safety, health and welfare agencies during times of emergency as the majority of the information that must be communicated becomes digital.
  8. I am aware of the app_rpt application. The hardware approach seems a bit redundant. (Using two FXS zapatel ports to talk to a special analog radio board.) Also rather expensive. Many hams have IRLP hardware, and that also runs on Linux. Wouldn't it be nice if there was an application that would provide the inter-operability in much the same manor we have added support for Echolink? The idea of having to have different hardware board for each VOIP system you want to support seems redundant. From what I understand the logic signals PTT/COR toggle the "call on hold" field and that's how the standard signaling is sent over a standard SIP/IAX stream. Configuring two SIP extensions isn't the worst. The part I don't like with the original is the hardware approach. That's why I think it would great of there was a GPL command line SIP client such as "linphonec" that could be torn apart and made to talk to the IRLP hardware board, since most of use are already using that hardware. For anyone interested here are some references: http://groups.yahoo.com/group/irlp/ http://groups.yahoo.com/group/EchoIRLP/ http://www.irlp.net/ http://groups.yahoo.com/group/asterisk_radio/ https://allstarlink.org/ http://asteriskpbx.org/ http://www.zapatatelephony.org/app_rpt.html