Sure. Here's the San Diego design currently being implemented;
And here's the corresponding detail of the top-level backbone and network management link. Note that AirOS's TDMA is used in bridge-mode... making the AREDN nodes act like they're all DTD-linked across a "switched" backbone.:
I'm a Newbie, so please don't crucify me. If the M3 devices are used with airOS, how is the station id every 10 minutes addressed to comply with part 97? The concept, by the way, is excellent!
K2VJK, the mesh nodes do a timed (crontab) every 5 min command. Could do same or similar technique and hook into AirOS, the linux command looks something like this:
Bill, the typical way to do this is to capture packets on the wireless interface of a node. This is not something configured in the AREDN images to do. It involves turning on the appropriate firewall rules and installing-running "tcpdump -i iwlan0-1 udp port 4919". With the appropriate options, the packets can be saved to a file and opened in wireshark to inspect.
Making the SSID your callsign may not actually work.
While I've routinely seen this suggested, the other day when i was thinking through the protocol I came across the realization that to my knowledge "Only the Access Point regularly broadcasts its SSID"(on average 10 times per second on a clear channel) a client in an AP network only really will transmit the SSID when it requests "does this network exist"
A normal wifi packet contains a BSSID identifier, which is a numerical identifier for the network, often based off the network name, but not directly likable to the network name (or in this case callsign) unless you have other information knowledge.
In the end if I recall all the relevant facets of the 802.11 protocol correctly, your left with only half your link identifying itself if you rely on the SSID to do identification in an AP network.
But yea, not sure the timing of all nodes sending this out for part 97 10 min needs... It's also not node specific, rather for all nodes of this RF mesh island that the callsign would be shown for. This may not be the desired licensing needed for each individual control operator.
The sample Beacon Frame you sent appears to be from an IBSS network (ad-hoc) like AREDN uses. In an ADHOC network EVERY device sends beacon frames so that everyone can be part of the 'adhoc" network.
AirOS does not support AdHoc it supports an AP/Client relationship.
In an AP network (to my knowledge) only the Access Point sends beacon frames. No other device associated to the access point transmits beacon frames in an AP network and is the reason for my comment that only one of the two transmitters would actually be identified if trying to go with the (often) suggested method of using callsign for the SSID.
Not to sidetrack this thread, but I am currently working on setting up a MESH deployment in my local area. We are working on getting it set up in time for the local marathon, which every year taxes our systems. These pictures are very close to what we have planned so far for a layout, multiple nodes mounted up as high as possible, with a 3 GHz. backbone. My biggest question is, in these pictures, there is a Raspberry Pi listed at each of the central nodes. I am wondering what purpose those strive at each site, and what programs they are running.
A reoccurring design principle is to keep your end nodes off of the backbone frequencies. For example, in the above pictures, 3.4GHz is used for the backbone, and then the backbone is connected to another band or frequency to feed the local mesh nodes.
That's my plan as well - I'm using a ham-only 5.9GHz channel for my point-to-point links, and then will use a ham-only 2.4GHz for the smaller area meshes.
Another principle here is that you don't necessarily need to use mesh for planned point-to-point links. I am using AREDN for that as part of my experimentation, but running ubiquiti gear in bridge mode would work just as good (and maybe even better with the airmax extensions). The only catch here is if you are using the ubiquiti software you won't be able to use the ham-only channels in the 2.4 and 5GHz bands.
Yep... and when you're forced to use the same band for multiple nodes at a site, use RF shielding and put as much frequency separation as possible between them.
Technically yes, there is nothing to sync under a CSMA because there is no coordination, its a 'first come first served' system.
Theoretically it could be a ''block transmit" feature however that doesn't even run smoothly (How do you deal with the fact that 2 different RF paths will probably not be able to agree with each other as when a good time to transmit is, when its good for one to transmit its not for the other, and when one is receive it could cause issues for the other, etc.
Multiple bands and wide spaced channels is probably the best we can do in reasonable future.
Ubiquiti from what I'm told didn't even do coordination between nodes unless they all had GPS receivers, otherwise it was solely timeslot from the central node and the remote nodes, with no concern for the other colocated devices on the same tower.
For Ubiquiti, the air Sync feature is a natural extension of TDMA. The situation with mesh/csma is analogous to a contest station, in which there are two stations on the same band (a 'run' station and a hunt-and-pounce 'multiplier' station). Contest rules forbid both stations from transmitting at the same time, so a lock out scheme is implemented. And they win contests.
In the case of mesh, we WANT the stations to transmit at the same time (so that they can receive at the same time, without self-interference). Instead of (or in addition to ) waiting some random time delay before transmitting, you would wait until your partner transmitter had something to send and then both radios would transmit at the same time. If the partner(s) had nothing to send, you would just go ahead as usual. This could be extended to inhibition while your partner was in the process of receiving something, as well. (In your spare time you might queue up a second message to be sent in cascade). This sort of coordination would require lightning-fast signaling between the partners. Ubiquiti uses GPS because there is too much latency on the eth ports. But they run very high data rates, compared to mesh, and they use the ports for, well, data. In our case, the port is unused and it might be possible to just toggle outputs not following any protocol and get sub-microsecond signaling.
CSMA works fine when the traffic is light. But, beyond a certain loading, it "falls off the cliff". That of course will be when you need it the most. In meshes where each node has, perhaps, only 2 neighbors, self-inflicted interference could be a substantial fraction of the total loading. If you could avoid it, that would be a substantial increase in the ability to handle heavy loading. In fact, this feature could just turn itself off (i.e., not inhibit) when traffic loading was light.
Ken
(Another contribution based on: 'everything is possible when you don't know what you are talking about')
kg9dw: This is same as my current plan of using AREDN beta 2 (maybe 4) in a rocket m5 in access point mode with ubiquiti omni antenna & client nodes with beams on 5ghz ch 179 (ham only) for connecting repeater towers and using rocket m2's with omni's at each site for local mesh users.
Also, here is a diagram i've been working on to start conversations at various groups, to generate interest and adoption. feel free to copy/edit/forward if you find it useful.
Too big, can't upload pdf either. i'll try to finish m3sh.net website and make it available there.
For monetary reasons, the first try will be using equipment I already own. A friend and I had set up a tiny wireless ISP in FL using Ubiquiti products. I have had great results with very few problems in the 12+ years of using their hardware. I have uploaded 3.15 to all. So far I have 2 rocket M2, a bullet M2HP & a loco M2. The main node to start with will be the bullet M2HP and a 12dBi Comet GP-24-3R (also from my former ISP). The plan is to run CH -2 on all nodes, with 10 MHz BW. Keeping my fellow HAM's in mind, using 2.4GHz parts for the "last mile" should keep costs down and adoption high.
Also, I want to use 5GHz devices for the point-point backbone (tower links) but I want to stay part 97 using HAM only freqs. Is there a way to use AREDN firmware in a point-point mode?
Sure Jim. AREDN firmware will work just fine for the network you described. While I believe the TDMA protocol will work more efficiently for fixed point-to-point links, it doesn't mean that CSMA/CA (the protocol AREDN firmware uses) won't work pretty well.
First let me apologize since I do not have time to properly get up to speed on products. Three days ago I accepted a donation of 2.4Ghz equipment in Michigan and am headed to Arizona in a week or so.
After two years of negotiating, I have received a grant for the Michigan amateur radio clubs to which I belong of some WIFI equipment.
I have not fully explored what I have, but I could bring some of the following to AZ for proof of concept testing this winter.
LMR400 cables with either N or RP-TNC connectors - 20, 50, 100, 150 ft lengths.
I also have a personal Rocket M2 and a Nanostation M2 and a couple of WRT54s and Netgear switch to get up to speed on tunnels.
I hope to explore interconnect of a clinic, school, firehall (all within a mile of each other) in Congress, AZ with a rec hall 4 miles away at North Ranch, AZ and then to a hospital in Wickenburg, AZ about 12 miles away.
What I learn this winter will then be brought back to my QTH in Michigan for similar application here.
All we can afford for now is 2.4Ghz equipment for proof of concept, but then can expand the backhauls to another freq.
If you are familiar with any of this equipment, I would appreciate comments - again my apologies for not having time to properly do my own homework.
Vance, the parts list has limited use for directly building an AREDN network. It looked like all the antennas were single element and not sufficient for the dual chain antenna needed for the rocket. You would still need a suitable antenna for the rocket. The nanostation, of course, has built in antenna.
Most of the gear you have is for indoor office wifi solutions. The Access Point 1200 series devices are capable of the light-weight AP protocols from cisco, but this requires a cisco wireless controller--which I do not see in the parts list. If you have access (or know someone) that can down load the 'autonomous' AP firmware from Cisco support, you would be able to turn these into standalone Access Points. These devices could be used to provide a typical part 15 wifi network at an incident site. This wifi network could then have a connection into an AREDN network, but not usable to directly create the AREDN network itself.
I'd recommend:
1) Consider a 2nd Nanostation to complement the one you have and build the ~1 mile link to get started. (It would cost as much to purchase a suitable antenna for the Rocket. Or consider purchasing an overkill rocket antenna for future use of much greater distant links.)
2) Use ch -2 @ 5Mhz or 10Mhz channel width to do your testing with the AREADN beta02 release (many of us are using this in our production networks already).
3) Assuming your switch has 802.1q capability (is a GS105E or GS108E netgear), then download a suitable config file from the AREDN downloads area. This will provide the ports necessary to setup the tunnel to others from one of the ubiquiti nodes.
4) The linksys has limited use in the configuration. It can't do ch -2 and would require surgery to configure ability to do DtDlink and connect it in the mesh as a node. I'd only recommend doing so if you need even more physical ports, but it is actually less hassle to get a 2nd netgear GS105E for ~$40 (multiple ports on each end of the link).
5) Consider purchasing a couple of VOIP ATA devices to do voice end-to-end. You'll want to test a service over the link. Alternatively, get an ipCam. Here's a basic get started low cost VOIP option for $35 each: http://www.amazon.com/Grandstream-GS-HT701-Handytone-Telephone-Adapter/d... . Once you plug a phone into each end, there's a way to do direct dial by using the IP addresses as the number (and then hit the phone's redial button to demo).
The value of most of the equipment I received is about what I expected, so will not bring much of that along.
I do have 3 Linksys IPSPA941 4 line phones and can get additional as needed. Last year we were running IP phone and full motion video at 5 miles with good success. My Rocket M2 has the big 120 sector antenna, so was thinking of bringing smaller antennas, but the Rocket package works well..
We are travelling in an ADA van because of my wife's power wheelchair, and so have only limited room for stuff.
I think that I will have to do some shopping when I get to AZ. I have been swamped getting ready to head south and really appreciate your response.
I'm told that OpenWRT has the capability to move transceiver chains into the Part 97 only sections of the bands of interest. I'm also told (haven't tried it yet myself) that the firmware installation process is somewhere between painful and agonizing. Hope to get a revised, simplified set of directions soon from KA6SOX.
AREDN already does this on top of OpenWRT. However, we modified OpenWRT's source code to add part 97 channel coverage. Maybe there's a channel or two by using OpenWRT stock firmware with International settings in the US? Is there a benefit that is desired not yet in AREDN?
We're veering off this thread's topic. Let's create another topic if carrying on more posts on this idea...
The channels at the top of 2.4 GHz 802.11 band are actually outside the Amateur allocation (2450 MHz top end).
You cannot do part 97 operation up there ...
Gentlemen,
This image has been posted on this thread a few times. While it is very extremely similar to what I have planned for MESH rollout in the local area, I am very curious as to one portion. Each node has a Raspberry Pi listed, what are the Pi's being used for and why? Not sure if I miss some crucial step or not. Any knowledge that can be offered would be greatly appreciated. While I am very familiar with microwave radios and transition sites, the networking side has always taken a lot more effort.
i think it's there to host applications such as:
MeshChat
Solar power monitoring system
etc.
(It's not required, but, provides a handy way to deploy apps that don't consume valuable node resources)
I was worried I was missing something needed for routing or network control. That would be a very handy way to cut down on network traffic. I am open to any suggestions about what would be best to put on a Raspberry Pi at each node. In the planning of this, everyone got very caught up in the initial shock of "we can do what?" but very little planning has gone into what is going to be sent over the network. Just that we can, and that excites people. I did some text examples of running Cisco phones over Asterisk, and an email server, but I am starting to question the practicality of using just one asterisk server to run all of the IP phones over the network, for many reasons.
Our VoIP forum moderator, Mark N2MH, successfully demonstrated and used several trunked Asterisk PBXs to support telephone communications at the last New York City marathon. I assisted a bit with the testing prior to deployment and saw this work just fine.
I did see the 2016 NYC Marathon in the Knowledge Base, and it sounds very similar to what we are trying to accomplish for our local marathon. We have a Boston Qualifier that covers a good amount of our metro area, and every year tests the limits of our local services. Any information you can share on setup and hardware would be greatly appreciated.
Sure. Here's the San Diego design currently being implemented;
And here's the corresponding detail of the top-level backbone and network management link. Note that AirOS's TDMA is used in bridge-mode... making the AREDN nodes act like they're all DTD-linked across a "switched" backbone.:
Sorry about the large image size.
Andre, K6AH
High-level Design
Detailed Design
I'm a Newbie, so please don't crucify me. If the M3 devices are used with airOS, how is the station id every 10 minutes addressed to comply with part 97? The concept, by the way, is excellent!
K2VJK, the mesh nodes do a timed (crontab) every 5 min command. Could do same or similar technique and hook into AirOS, the linux command looks something like this:
echo "ID: AE6XE" | socat - udp4:10.255.255.255:4919,broadcast,so-bindtodevice=wlan0
An easier way, just make the SSID your callsign for this P2P link.
Joe AE6XE
Given the beacon command:
echo "ID: AE6XE" | socat - udp4:10.255.255.255:4919,broadcast,so-bindtodevice=wlan0
Is there a parallel related socat or similar operation to monitor on a node for transmissions it hears?
Thanks,
Bill - WA7NWP
Bill, the typical way to do this is to capture packets on the wireless interface of a node. This is not something configured in the AREDN images to do. It involves turning on the appropriate firewall rules and installing-running "tcpdump -i iwlan0-1 udp port 4919". With the appropriate options, the packets can be saved to a file and opened in wireshark to inspect.
Thank you for the note Joe.
Making the SSID your callsign may not actually work.
While I've routinely seen this suggested, the other day when i was thinking through the protocol I came across the realization that to my knowledge "Only the Access Point regularly broadcasts its SSID"(on average 10 times per second on a clear channel) a client in an AP network only really will transmit the SSID when it requests "does this network exist"
A normal wifi packet contains a BSSID identifier, which is a numerical identifier for the network, often based off the network name, but not directly likable to the network name (or in this case callsign) unless you have other information knowledge.
In the end if I recall all the relevant facets of the 802.11 protocol correctly, your left with only half your link identifying itself if you rely on the SSID to do identification in an AP network.
Looks like the driver is currently sending the SSID text in the beacon (received on a Rocket M3):
20:17:52.852447 10165594217904us tsft 3.0 Mb/s 5420 MHz 11a/10Mhz -75dB signal [bit 29] Beacon (AREDN-10-v3) [6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0 Mbit] IBSS
But yea, not sure the timing of all nodes sending this out for part 97 10 min needs... It's also not node specific, rather for all nodes of this RF mesh island that the callsign would be shown for. This may not be the desired licensing needed for each individual control operator.
The sample Beacon Frame you sent appears to be from an IBSS network (ad-hoc) like AREDN uses. In an ADHOC network EVERY device sends beacon frames so that everyone can be part of the 'adhoc" network.
AirOS does not support AdHoc it supports an AP/Client relationship.
In an AP network (to my knowledge) only the Access Point sends beacon frames. No other device associated to the access point transmits beacon frames in an AP network and is the reason for my comment that only one of the two transmitters would actually be identified if trying to go with the (often) suggested method of using callsign for the SSID.
Not to sidetrack this thread, but I am currently working on setting up a MESH deployment in my local area. We are working on getting it set up in time for the local marathon, which every year taxes our systems. These pictures are very close to what we have planned so far for a layout, multiple nodes mounted up as high as possible, with a 3 GHz. backbone. My biggest question is, in these pictures, there is a Raspberry Pi listed at each of the central nodes. I am wondering what purpose those strive at each site, and what programs they are running.
A reoccurring design principle is to keep your end nodes off of the backbone frequencies. For example, in the above pictures, 3.4GHz is used for the backbone, and then the backbone is connected to another band or frequency to feed the local mesh nodes.
That's my plan as well - I'm using a ham-only 5.9GHz channel for my point-to-point links, and then will use a ham-only 2.4GHz for the smaller area meshes.
Another principle here is that you don't necessarily need to use mesh for planned point-to-point links. I am using AREDN for that as part of my experimentation, but running ubiquiti gear in bridge mode would work just as good (and maybe even better with the airmax extensions). The only catch here is if you are using the ubiquiti software you won't be able to use the ham-only channels in the 2.4 and 5GHz bands.
Good luck to all! 73 de KG9DW
RE: "The only catch here is if you are using the ubiquiti software you won't be able to use the ham-only channels in the 2.4 and 5GHz bands."
thus the choice if 3Ghz band nodes.. ;-)
Yep... and when you're forced to use the same band for multiple nodes at a site, use RF shielding and put as much frequency separation as possible between them.
Andre, K6AH
now here is a use for that second port on the nano station. Use it to synchronize the transmitters of co-located same-band radios ;-)
Ken
i think sync is only applicable to TDMA. right?
Technically yes, there is nothing to sync under a CSMA because there is no coordination, its a 'first come first served' system.
Theoretically it could be a ''block transmit" feature however that doesn't even run smoothly (How do you deal with the fact that 2 different RF paths will probably not be able to agree with each other as when a good time to transmit is, when its good for one to transmit its not for the other, and when one is receive it could cause issues for the other, etc.
Multiple bands and wide spaced channels is probably the best we can do in reasonable future.
Ubiquiti from what I'm told didn't even do coordination between nodes unless they all had GPS receivers, otherwise it was solely timeslot from the central node and the remote nodes, with no concern for the other colocated devices on the same tower.
For Ubiquiti, the air Sync feature is a natural extension of TDMA. The situation with mesh/csma is analogous to a contest station, in which there are two stations on the same band (a 'run' station and a hunt-and-pounce 'multiplier' station). Contest rules forbid both stations from transmitting at the same time, so a lock out scheme is implemented. And they win contests.
In the case of mesh, we WANT the stations to transmit at the same time (so that they can receive at the same time, without self-interference). Instead of (or in addition to ) waiting some random time delay before transmitting, you would wait until your partner transmitter had something to send and then both radios would transmit at the same time. If the partner(s) had nothing to send, you would just go ahead as usual. This could be extended to inhibition while your partner was in the process of receiving something, as well. (In your spare time you might queue up a second message to be sent in cascade). This sort of coordination would require lightning-fast signaling between the partners. Ubiquiti uses GPS because there is too much latency on the eth ports. But they run very high data rates, compared to mesh, and they use the ports for, well, data. In our case, the port is unused and it might be possible to just toggle outputs not following any protocol and get sub-microsecond signaling.
CSMA works fine when the traffic is light. But, beyond a certain loading, it "falls off the cliff". That of course will be when you need it the most. In meshes where each node has, perhaps, only 2 neighbors, self-inflicted interference could be a substantial fraction of the total loading. If you could avoid it, that would be a substantial increase in the ability to handle heavy loading. In fact, this feature could just turn itself off (i.e., not inhibit) when traffic loading was light.
Ken
(Another contribution based on: 'everything is possible when you don't know what you are talking about')
:-)
Thanks for all the drawings and input!
kg9dw: This is same as my current plan of using AREDN beta 2 (maybe 4) in a rocket m5 in access point mode with ubiquiti omni antenna & client nodes with beams on 5ghz ch 179 (ham only) for connecting repeater towers and using rocket m2's with omni's at each site for local mesh users.
Also, here is a diagram i've been working on to start conversations at various groups, to generate interest and adoption. feel free to copy/edit/forward if you find it useful.
Too big, can't upload pdf either. i'll try to finish m3sh.net website and make it available there.
Thanks for all the replies!
For monetary reasons, the first try will be using equipment I already own. A friend and I had set up a tiny wireless ISP in FL using Ubiquiti products. I have had great results with very few problems in the 12+ years of using their hardware. I have uploaded 3.15 to all. So far I have 2 rocket M2, a bullet M2HP & a loco M2. The main node to start with will be the bullet M2HP and a 12dBi Comet GP-24-3R (also from my former ISP). The plan is to run CH -2 on all nodes, with 10 MHz BW. Keeping my fellow HAM's in mind, using 2.4GHz parts for the "last mile" should keep costs down and adoption high.
Also, I want to use 5GHz devices for the point-point backbone (tower links) but I want to stay part 97 using HAM only freqs. Is there a way to use AREDN firmware in a point-point mode?
Sure Jim. AREDN firmware will work just fine for the network you described. While I believe the TDMA protocol will work more efficiently for fixed point-to-point links, it doesn't mean that CSMA/CA (the protocol AREDN firmware uses) won't work pretty well.
Andre, K6AH
First let me apologize since I do not have time to properly get up to speed on products. Three days ago I accepted a donation of 2.4Ghz equipment in Michigan and am headed to Arizona in a week or so.
After two years of negotiating, I have received a grant for the Michigan amateur radio clubs to which I belong of some WIFI equipment.
Vance, the parts list has limited use for directly building an AREDN network. It looked like all the antennas were single element and not sufficient for the dual chain antenna needed for the rocket. You would still need a suitable antenna for the rocket. The nanostation, of course, has built in antenna.
Most of the gear you have is for indoor office wifi solutions. The Access Point 1200 series devices are capable of the light-weight AP protocols from cisco, but this requires a cisco wireless controller--which I do not see in the parts list. If you have access (or know someone) that can down load the 'autonomous' AP firmware from Cisco support, you would be able to turn these into standalone Access Points. These devices could be used to provide a typical part 15 wifi network at an incident site. This wifi network could then have a connection into an AREDN network, but not usable to directly create the AREDN network itself.
I'd recommend:
1) Consider a 2nd Nanostation to complement the one you have and build the ~1 mile link to get started. (It would cost as much to purchase a suitable antenna for the Rocket. Or consider purchasing an overkill rocket antenna for future use of much greater distant links.)
2) Use ch -2 @ 5Mhz or 10Mhz channel width to do your testing with the AREADN beta02 release (many of us are using this in our production networks already).
3) Assuming your switch has 802.1q capability (is a GS105E or GS108E netgear), then download a suitable config file from the AREDN downloads area. This will provide the ports necessary to setup the tunnel to others from one of the ubiquiti nodes.
4) The linksys has limited use in the configuration. It can't do ch -2 and would require surgery to configure ability to do DtDlink and connect it in the mesh as a node. I'd only recommend doing so if you need even more physical ports, but it is actually less hassle to get a 2nd netgear GS105E for ~$40 (multiple ports on each end of the link).
5) Consider purchasing a couple of VOIP ATA devices to do voice end-to-end. You'll want to test a service over the link. Alternatively, get an ipCam. Here's a basic get started low cost VOIP option for $35 each: http://www.amazon.com/Grandstream-GS-HT701-Handytone-Telephone-Adapter/d... . Once you plug a phone into each end, there's a way to do direct dial by using the IP addresses as the number (and then hit the phone's redial button to demo).
Joe AE6XE
Thanks Joe
The value of most of the equipment I received is about what I expected, so will not bring much of that along.
I do have 3 Linksys IPSPA941 4 line phones and can get additional as needed. Last year we were running IP phone and full motion video at 5 miles with good success. My Rocket M2 has the big 120 sector antenna, so was thinking of bringing smaller antennas, but the Rocket package works well..
We are travelling in an ADA van because of my wife's power wheelchair, and so have only limited room for stuff.
I think that I will have to do some shopping when I get to AZ. I have been swamped getting ready to head south and really appreciate your response.
Thanks again
AREDN already does this on top of OpenWRT. However, we modified OpenWRT's source code to add part 97 channel coverage. Maybe there's a channel or two by using OpenWRT stock firmware with International settings in the US? Is there a benefit that is desired not yet in AREDN?
We're veering off this thread's topic. Let's create another topic if carrying on more posts on this idea...
The channels at the top of 2.4 GHz 802.11 band are actually outside the Amateur allocation (2450 MHz top end).
You cannot do part 97 operation up there ...
Gentlemen,
This image has been posted on this thread a few times. While it is very extremely similar to what I have planned for MESH rollout in the local area, I am very curious as to one portion. Each node has a Raspberry Pi listed, what are the Pi's being used for and why? Not sure if I miss some crucial step or not. Any knowledge that can be offered would be greatly appreciated. While I am very familiar with microwave radios and transition sites, the networking side has always taken a lot more effort.
MeshChat
Solar power monitoring system
etc.
(It's not required, but, provides a handy way to deploy apps that don't consume valuable node resources)
I was worried I was missing something needed for routing or network control. That would be a very handy way to cut down on network traffic. I am open to any suggestions about what would be best to put on a Raspberry Pi at each node. In the planning of this, everyone got very caught up in the initial shock of "we can do what?" but very little planning has gone into what is going to be sent over the network. Just that we can, and that excites people. I did some text examples of running Cisco phones over Asterisk, and an email server, but I am starting to question the practicality of using just one asterisk server to run all of the IP phones over the network, for many reasons.
I did see the 2016 NYC Marathon in the Knowledge Base, and it sounds very similar to what we are trying to accomplish for our local marathon. We have a Boston Qualifier that covers a good amount of our metro area, and every year tests the limits of our local services. Any information you can share on setup and hardware would be greatly appreciated.
Contact me at callsign@arrl.net offline and I'll be happy to fill you in.
Mark, N2MH