I am trying to flash a Bullet M2-HP from bbhn 1.0.1 to 3.0.0. The firmware will upload to the Bullet from my laptop but will not flash. I get a message saying "Firmware CANNOT be updated the uploaded file is not recognized". Any suggestions are greatly appreciated.

Thanks

Dave KM2O

I have 3 WRT54Gs and one Ubiquity Bullet M2.  All were connected fine via RF on CH 1.  In an effort to minimize interference over a 20 mile path to another station, we decided on CH 3.  The bullet connected fine to the remote station on CH 3 (across the Las Vegas valley, I might add :) - still fine tuning though).

I changed the 3 WRT54Gs to CH 3; their physical locations remained unchanged.  Applied the change, used the "Save Changes" button and rebooted each of them.  They see each other, but not the bullet.  Oddly, I know I noticed that when I changed the first one to CH 3, it still saw the other two that I hadn't changed yet from CH 1.  At that point, I chalked it up to being tired / a fluke.

A WiFi scan from the bullet, and from at least one of the WRT54Gs, shows BroadbandHamnet-20-v3 on CH 1 (not CH 3!) (the bullet also shows a second entry - the remote station's -71 signal on CH 3).

I'm coming to the conclusion that for whatever reason, changing the channel on the WRT54Gs had no effect - is this a known issue?  

I know I can work around the 3 nodes being on RF only paths with the bullet; it was just my inability to replicate my original setup that was frustrating since everything worked fine on CH 1. 

AE4ML, have you noticed how many commas are in the WebEOC price tag?

There is a reason only governments use it :-)

73

Jim

Update:  I rebooted the computers and the routers - after walking away and having dinner.  For some reason the routers accepted the username and passwords.  

Both nodes are running and they see each other wirelessly.  Now, I just need to learn how to make both nodes interact with each other.  I see a lot of reading in my future.

========

I am having the same problem.  I just flashed two WRT54GL ver 1.1 (using the latest .bin file) and everything appeared to install properly.  I entered my node name  w8mrl-1 and w8mrl-2 and the same password on both of them.

When I try to enter setup it won't accept my username and password.  I've tried multiple times on both units and can't get into setup.

Is this a bug?  Seeing that I'm having the same issue as the previous post?

Fixed... it turns out that the ntpclient wouldn't accept an update from my server since the variation from Jan 1, 2000 was too great. I changed the switches in /etc/init.d/ntpclient from adjtimex(2) [-l] to Trusted Server [-t] to prevent RFC-4330 crosschecks. Then, for the time being I changed the target to the Lan address since it is, after all, a closed network. All the clocks updated immediately upon reboot.

#!/bin/sh /etc/rc.common

START=70 start() {

{

while ! ping -c1 kb1tkm-ntp.local.mesh >/dev/null 2>&1; do sleep 60; done

/usr/sbin/ntpclient -s -t -h kb1tkm-ntp.local.mesh >/dev/null 2>&1;

} &

} stop()

{ killall ntpclient }

I decided to merely run the NTP server as an advertised service temporarily as I'm working now to integrate the DNS and NTP servers onto one piece of hardware. Once that is finished, changing the target NTP server name in this script will no longer be necessary.

I may have to play with Tidepools. Will have to add it to my list of virtual machines.

Maybe a RPi Docker solution would be pretty cool for these!??!?! hmm...

Very Interesting. though I don't think it would meed the specific needs of incident reporting. However, one of the more difficult aspects of getting any community effort going is finding the specific set of activities and benefits that keep people "coming back for more."

Adding Tidepools, or something in that vein, might be the "killer app" that gets people involved and make the mesh part of their general day-to-day lives.  Them when SHTF use of the network is second nature.

BTW, I am now looking at the Bugzilla and Redmine bug tracking systems. They both have a structure that could map well onto the CERT communications plans. I need to see which one allows the most customization and is the easiest to use.  I will post my findings back here if there is interest.

Thanks!

Richard - wb6tae

I wonder if the tidepools system would fit your needs?

Here is a writeup on how it was used during Huricane Sandy, this was part of a community wifi project that is somewhat similar in how Ham Radio would be used in a disaster

http://techpresident.com/news/23127/red-hook-mesh-network-connects-sandy-survivors-still-without-power

http://oti.newamerica.net/sites/newamerica.net/files/articles/rhiwifi_tidepools_casestudy.pdf

http://tidepools.co/

It isn't a ticket system  but maybe it fits the needs of what you want?

Yeah, I could have been a bit more specific. What we are looking to provide is a means for individual neighborhood CERT teams to report local incidents in a post disaster (that means earthquake in California) environment.  In this situation the local response agencies (fire, paramedics, police, etc.) have been pretty clear that there is no point in trying to contact them in the immediate post quake period - they will be 100% occupied. However, they do want to be able to still collect reports and be able to review or respond later as may be appropriate. At the very least, this data would be of statistical value.

So, there is no real need to manage dispatches and things like that. But, some minimal ability to feedback to the neighborhood that the report was seen, and might be acted on, is important.

I have have installed ticketscad on a R-Pi and it covers the territory, plus much much more. It also runs a little slowly on a Pi b+, I am waiting for a Pi 2 ;-)

I am also in the process of installing Bugzilla to see if it can be customized for our needs.

Not sure what the nature of the "incident" is, but if it involves Search and Rescue, you might touch base with Vance, KC8RGO on this forum.  He's implementing an Incident Management system called SARTRACK over the mesh:  http://www.sartrack.co.nz

There is also WebEOC which is used by many local emergency agencies.: https://www.intermedix.com/product/product-webeoc/index.php 

Andre

Thanks.  Looks interesting, and more focused on emcomm than a general ticket tracking system. Do you have any experience installing ticketscad on an R-Pi/Debian or other Linux?

The major focus of our mesh network is going to be Emergency Communications. We are looking at, and testing, various implementations of email, chat, VoIP, video, file sharing, etc. to deploy on the network.

One service in particular has been hard to find: Incident Tracking. The few systems I can find are very large, complex and, usually, expensive. What we would like is something lightweight, with web based access and the ability to create reporting groups (like neighborhoods) and targets (like agencies, fire, police, etc.). Input should be easy to manage: subject, description, severity, status, assigned to, expected clearing, expected update.  Reporting should allow input units to see their reports and target unites to see their reports. There should also be minimal dependency on other external software packages and the system should be able to maintain multiple redundant copies of the data with multiple access URLs. (Cloud based).

As I noted above, I have not found anything that is advertised as delivering the requirements I noted above. However, it has occurred to me that software "bug tracking" systems, like the Bloodhound system used by the bbhn team, might actually meet our needs.

So, does anyone here have experience in this type of application and, if so, what are your experiences and what advice would you offer?

Richard - wb6tae

I think this (WRT54x) is an issue that is just not going to go away, and will, in the long run, actually delay broader implementation of 2.4gHz spectrum usage.  

People seems blinded by the initial cost of acquiring a "vintage" Linksys router. They do not consider the other costs and implications of actually deploying these radios in a network -- Antenna, waterproof box, etc., or the cost, and loss, associated with coax.  Of course there are other issues as well, like limited memory in many models, and much lower output power.

But, all of this has been discussed many times on this board and in meetings, hamfests, etc. Yet, the Linksys products still seem to be the entry level radio of choice for 2.4gHz networking.

I suspect this is, in part, an objection the the current Ubiquiti monopoly on equipment: nobody is comfortable with single-sourcing for any project. Hopefully we will be able to add support for at least one, new vendor in 2015, and maybe another in 2016. Increasing the source pool (along with dropping support for the Linksys products) may be the push that is needed.

My 2¢

Richard - wb6tae

Great turnout this weekend for the BBHN presentation at the Yuma Hamfest.  Thanks to all who turned out for it and the afternoon workshop.  

Andre, K6AH

i tend to agree.  I feel that the lack of posts regarding 3.0 is a good sign.  I know, in my business, I rarely hear about the good things happening, but, when things are going bad... whew.  look out.

;-)

All of my nodes are 3.0.1 and working very very well!

I am not sure about the advantage of being behind. In many cases, especially where a group of users must adhere to the same release level, being "behind" forces new users to start with obsolete software and then have to upgrade, perhaps soon after getting started  I can certainly understand not wanting to be on the bleeding edge. But, I would also not use a lack of posts as a sign of trouble.

Of course, YMMV

Richard - wb6tae