I'm having issues setting up Hamchat also, if possible, I'd appreciate any assistance.All files have been created , but I'm having problems installing the hamchat.pl file.

Thanks

Ted KK4LXY

ted dot kruger at gmail dot com

Wow, so much to know and learn.  Thanks to Joe and Conrad for their help and insight.  It looks like my evaluation of the IT-24 may not be truthful/accurate because of all the variables involved... not like the days of a Bird-43, steady carrier transmitters and dummy loads!

I'll keep researching away... gotta learn somehow!

Boyd, K5YKG

It would be great to have a mesh-wide power monitoring application using a derivative of the cron job listed below.  Is there any way that DC supply voltage to a node can be read and stored?  This data would then be remotely monitored for node 'health'.  This would be HUGE for long-term emcomm applications where system up-time is critical.  

73 from St. Croix de NP2X

The camera itself will not generate any content unless another client is pulling that data.

The frames may be small if it's real time video or may be large all depends on settings.

Power output is affected by other nodes.

The only true proper way to do this is in a faraday cage and you MUST know low level commands to control RF settings (more controllable under Ubiquiti than Linksys) to control the device under test.

WIFI devices will vary the power up and down based on the speed they are transmitting at.

With an IP camera hooked up to a mesh node (WRT54Gv4), with one antenna removed and the IT-24 connected to the other antenna output (RP-TNC male) and the 'Set_up' screen directing T&R packets to the left connector, I am measuring 13.8 dBm (23.7 mW) per the IT-24 which displays both dBm and mW values.  The IT-24 is "supposed" to measure PEAK power.  The Linksys advertizes 19 dBm.  If this is all the proper way to do the measuring, does this seem typical?

I am assuming (ass u me !) that the camera will cause the node to generate longer packets.  Is my thinking correct?

Boyd

First off:

Just using this just to pair PC's to a node would pollute  the RF.  This is unwise and highly recomended against.

Put up a wireless access point on channel 11 instead to do this. It is cleaner for the RF network and will have better performance.

Beyond that there *may* be a bug in OLSR as distributed by many distributions that does not function correctly on 64bit systems (unconfirmed)

Beacon's in WIFI are short bursts that send out basic wifi details.  As notes by me before they are very short packets.

We do not disable beacons. Any AP or Mesh node will send beacons.

Yes, I read about that in the IT-24 manual and used the mesh node's Set-Up page to put the node into the AP mode but didn't know how to invoke the "Beacon Mode", figuring that might give me longer transmissions. Any suggestions or info about the "Beacon Mode"?

Thanks Boyd Prestwood, K5YKG

Near Houston in NW Harris Co

I have had this same problem with a WRT54G VERSION 2.0 at my location. I have also reloaded the software twice (once by RF link because I couldn't talk to it on the Ethernet) #### Still scratching my head over that one but much more to do to upgrade my network to 1.1.2. 73 Dave WA5DJJ

http://www.wrtnode.com/

I was able to buy 5 linksys units with the software already loaded.  I got them up and running and they see each other.  I changed the node names and the passwords.  I won't have them all up 24/7 but maybe I'll leave one on  in case someone wants to see if they can reach it.  These are stock linksys 54g boxes.  I tried passing internet access through but no luck.  I am just beginning to read the articles on this site about the different applications. 

Under the hood of olsr...

After further research into this and looking under the hood in 1.1.x BBHN release, it is a different ball game from my first post. Introduced in the 1.1.x release is Device to Device (DtD) bridging of nodes with a cat5 network cable. This requires usage of the "ffeth" Link Quality (LQ) algorithm which is incompatible with prior methods. "ffeth" was added to handle ETX values < 1. '1' is considered a perfect RF link and this algorithm uses '0.1' value for ethernet links.

Trivia: ffeth = Funkfeuer/Freifunk (the guys that wrote the implementation) + ethernet support in olsr

So what is the algorithm used to determine Link Quality (LQ) which is used to calculate Expected Transmission Count (ETX)?

Short answer: The % of the last 32 Hello packets received from a node (in ~64 seconds) + bias due to several packets lost in a row (link may have dropped so don't wait ~40 secs before declaring it dead)

Long answer: here's the code :) :

/* calculate link quality */

/* LQ_FFETH_WINDOW = 32 */

/* lq.valueLq = 255 is 100% LQ and 0 is 0% LQ */

244 if (total == 0) {

245 tlq->lq.valueLq = 0;

246 } else {

247 // start with link-loss-factor

248 ratio = fpmidiv(itofpm(link->loss_link_multiplier), LINK_LOSS_MULTIPLIER);

249

250 /* keep missed hello periods in mind (round up hello interval to seconds) */

251 if (tlq->missed_hellos > 1) {

252 received = received - received * tlq->missed_hellos * link->inter->hello_etime/1000 / LQ_FFETH_WINDOW;

253 }

254

255 // calculate received/total factor

256 ratio = fpmmuli(ratio, received);

257 ratio = fpmidiv(ratio, total);

258 ratio = fpmmuli(ratio, 255);

259

260 tlq->lq.valueLq = (uint8_t) (fpmtoi(ratio));

261 }

262

263 /* ethernet booster */

264 if (link->inter->mode == IF_MODE_ETHER) {

265 if (tlq->lq.valueLq > (uint8_t)(0.95 *

255)) {

266 tlq->perfect_eth = true;

267 }

268 else if (tlq->lq.valueLq > (uint8_t)(0.90 * 255)) {

269 tlq->perfect_eth = false;

270 }

271

272 if (tlq->perfect_eth) {

273 tlq->lq.valueLq = 255;

274 }

275 }

276 else if (link->inter->mode != IF_MODE_ETHER && tlq->lq.valueLq > 0) {

277 tlq->lq.valueLq--;

278 }

1) BroadbandHamnet-v2
2) Yes. Most notable one: SSH/2222
3) The RPi is not supported by the team. There were some changes and re-implementations that can be found on changelog/documentation on the side pannel. The Non-BBHN developer who worked on the code has yet to update it. You are right that you should be able to just change the SSID to match that of the m2m network, but what is going on in the configuration level of supported BBHN firmware is a little different.

1) I'm confused.  I downloaded code and flashed my WRT54GS and it comes up with SSID

   "BroadbandHamnet-v2",   I also got the git files for my Raspberry PI, but it comes up with SSID

   "HSMM-MESH".   Which is it to be?

2) Besides the web setup on the WRT54GS, by default is there any other access to the WRT via

    telnet and/or ssh?

3) I've been working for a few years on real mesh networks (ie 802.11S).   In a nutshell you take

   any wireless interface (lets say wlan0) and using various iwconfig/iw commands you add a new

   mesh interface on top of the wlan0 interface.   I have 3 PI computers that talk together over

   a mesh, and when I switch all to "BroadbandHamnet-v2" on channel 1, they see each other BUT

   don't see the WRT box :-(  The 4th pi which came up on HSMM-MESH and modified to the same

   SSID also doesn't see the working mesh.