@Heater
Apparently if you top off the file system, the Openwrt fails and you have to go into Failsafe mode to dump the extra files. Of course, if you provide a binary that consumes too much space, dumping via Failsafe may not work. You will have to recompile and provide a smaller image. Failsafe mode can also load a new binary. So you haven't bricked the MR3020. .... but you do need to access the RS232 Tx and Rx to navigate Failsafe mode.
For using the Serial Console via Tx and Rx...
If you have a cable for direct plug in to the Propeller and don't want to change it, you will have to create a tiny 'null modem' cable of 3 wires (GND, Tx, and Rx) that crosses over Tx and Rx. Then you can just use a PropPlug or USB2SER to get into the MR3020 at 115200 8N1 for Failsafe operations.
~~~~~~~~~~~~~~~~~~~~~~~~~~~
That pesky Reset problem...
I am satisfied that pi-propeller-load is working right, but there is something about GPIO to Reset configuration that is NOT 100% stable. My best solution is to disconnect it when not loading binaries.
I can set up the GPIO29 to export/out/high and reach Forth on the Propeller.
I then set four LEDs on i/o pins 1 to 4 to light and leave this to run.
When I come back in an hour or so, the LEDs are all out. This seems to indicate a Reset has been triggered.
Going into the MR3020 logs, the device seems to have NOT reset.
And checking the GPIO29 configuration still shows export/out/high.
So I am not sure of the source of the Reset or if measures that Heater applied to his D-Link are necessary.
++++++++++
For my own communications use, I find that having just the Tx and Rx connected to Forth on the Propeller to be rock solid stable. I can leave that for long-term wifi communications.
It is only when I desire to load binaries that I need the Reset.
In SUM, for a wireless programmer, the current setup is fine. Very feasible for a bunch of students sharing one wifi programmer in a classroom setting.
For wifi robotics, one may have to disconnect the Reset and just use the Tx and Rx. Forth isn't the only way to do this. There is interpreted Basic and one can write up their own serial interface. If one needs to reset the Propeller over wifi, one can create a 'reboot' command that will do so.
I am satisfied with what I have now. But Heater may want that Reset to be rock-solid. I am beginning to wonder if these SoC chips might occasionally poll and toggle all the export configured GPIO. I would have to set up a Propeller that monitors the Reset line and logs the time interval between resets to determine if they are regular or sporadic. I think that might settle the speculation on RFI causing resets or something in the SoC GPIO setup being the source.
I'm back to a fresh install on the MR3020. I was stuck, file system full, could not install 3G USB packages, could not uninstall Luci to make room. Stuffed up, no place to go.
But I was still logged in via SSH so thinking about it I just deleted a bunch of files that looked redundant for now, clearing up a bit of free space. Then hit the firmware "flash button" in Luci. It worked. Phew!
So now I back to a minimal OpenWRT install with lot's of free space.
The only thing I was thinking of reporting as a bug was that business of opkg not finding it's Package.gz file on line. But the new install, built fom latest sources, has fixed that anyway.
The "chaos calmer" thing was a surprise. It just happens to be what you get well you pull the latest sources from git.
@Loopy,
Yep. When the file system gets full all kind of stuff starts to to not work in odd ways. Luckily I managed to avoid any messing with fail safe mode this time.
According the the instructions on building OpenWrt if you try to buld a binary that is too big to fit your device it won't do it.
For sure I will be setting up a little cable to get serial connection via a Prop Plug. I always feel safer with a "back door" console connection.
Your random reset problem sounds very much like what I had. Any long wire hanging off the Propeller reset acts like an antenna and can pick up all kind of disturbances. Years ago I had such a set up and it used act as a very good "fridge monitor", it would reset whenever the refrigerator in the house turned on or off!
Adding the 10K pull up to reset, 10 or 100nF to ground and 100 ohms in series with that antenna fixed it for the D-LINK connection. But I'm still not sure if that is an optimal solution.
I don't agree with your conclusion. If what we have here is a hardware problem, sensitivity to external electrical disturbance, then that hardware problem should be addressed. Changing programming languages is not the solution.
There is a possibility that something in OpenWRT is hitting the GPIO unexpectedly, like it does with that blue LED on power up on my D-LINK. Unlikely but possible. If so we have to track it down and stop it.
I might just forget the issue 3G USB dongle configuration and put Luci back on the MR3020 for now. Better to get the Propeller link working first.
@Heater
Well it seems I have to follow your agenda of tracking down the spurious Reset, or move on to my own desire to get the MR3020 to operate in STA mode as a stand alone wifi device.
I really can't do both at the same time. I do admit that I have an A/C right next to where the MR3020 is running and that could trigger a reset.
It is not that I am satisfied with the spurious reset issue. It is that I am satisfied with the idea of programing the Propeller through Forth and avoiding the problem altogether.
But the possiblilty of a spurious reset puts all GPIO uses into question... not just the Reset. The 4 LEDs I do have on the MR3020 seem to flicker at times. I will watch that in terms of what the A/C is doing when they flicker.
_________
I have to move on to filing my 2013 Income Tax, which is on an extended filing. So I am not going to spend as much time as I'd like with the MR3020 for a few weeks.
I will try some long-term LED test with the Reset/GPIO disconnected and see if I am satisfied with the stability.
heater,
Interesting about Chaos Calmer. That is the current development version thayt they hope to release around Xmas. The release version is in RC3 (the other day) and is B... B... (cannot recall ist name). This is all on the OpenWRT.org home page.
For the time being, if you can get by working around the reset problem, I will look at it later - having too much fun with the P1 FPGA atm. But I do have to get this running so I have to order some boards shortly.
For what it is worth....
I removed the Reset attached to GPIO29 from my Propeller and just used the Tx and Rx attached. The Propeller remains stable, no reset for more that 24 hours, whereas I was getting spurious resets within an hour when I had the GPIO29 connected to the Propeller's Reset.
It does seem to require a ground loop or a complete circuit to involve the spurious reset. I left the wire from the GPIO29 attached to the Propeller Reset, so there was the equivalent of an 8" antenna attached to the Propeller's Reset. That alone is not enough. This might explain why the 100pf capacitor to ground is helpful.
I can insert Heater's scheme to filter unwanted resets and see how that works.
But the point is there are two alternatives -- [a] do without a Reset after programming, add circuitry to stabilize the Reset.
+++++++++++++
I still haven't perfected a configuration for wifi only, without a LAN connection. But it seems that should be easy.
I wanted my MR3020 to act as an autonomous programmer and communications device with the Propeller. Heater suggested I reconfigure to STA mode from AP mode for that. But I spent quite a bit of time with this not seeming to work.
It now seems that you have to use a Trunk firmware image to have STA included as an alternative in the firmware, maybe not available in Attitude Adjustment v12.09.
IOW, there is a lot that one has to learn about the OpenWrt way to become creative with it.
Here is a snippette from the Wireless Configuration HTML that seems to point the way. I guess I have to compile and load a fresh firmware image to have all and everything to play with.
'mac80211 STA mode supported on trunk. STA and AP at the same time is not yet
supported(r22989).'
I have been away from home most of the week so I had little chance to get on the net and check the action here.
Whether you use your WIFI as a station or access point is somewhat independent of whether you are using the unit as a Prop programmer or not.
I just imagined that one might have many units around the house, or boat it Cluso's case, in which case having them as stations connecting to a central access point is probably what you want to do.
I think you should just bite the bullet and check out the OpenWRT sources from trunk and build your own image. Then you also have the tool chain ready for building the loader or anything else you want to do.
Having your own sources means you can easily build an image for some other platform you get hold of. Like that Raspberry Pi you are itching to try out
At this point, getting a Trunk image (the main development path of source code which is fresher and changing) and compiling it is not really a big issue
My real problem was not catching in the OpenWrt on-line documents that a STA mode required such.
I started out with Attitude Adjustment V12.09 because of all sorts of warnings about the stability of images compiled from Trunk. But it seems that one can only go so far with a conservative approach. And in my case, I got stuck with every reconfiguration to STA mode shutting me out of the MR3020.
And so, I will recompile (there is a GIT repository) and load a latest Trunk image. From there, I should be able to get STA mode, and quite a few other features. Of course, like Heater, I may have to get my packages from elsewhere -- so it is a good idea to compile all those for yourself at the same time.
So, I am just making sure others understand how to get the most out of OpenWrt. Aptitude Adjustment and Barrier Breaker may really just be for those that want to have a stable custom router. Here, we are getting out into more creative things. I also see that Trunk in required if there is a desire to build a Mesh network of wifi... that also appeals to me.
I would not worry about packages when using trunk. I found that my build of trunk from sources ends up fetching packages from snapshots of trunk that seem to be built everyday from the latest sources. Here: https://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/
Of course things can go wrong with software under development. For example for a few days I could not load any packages as the trunk version of opkg was configured wrongly out of the box. But hey, we are all hackers here aren't we?
I was getting curious about the mesh idea the other day. Turns out we have a dozen or so ISEE IGEP boards in the office that may never be used. Like Beagles only better. They all have WIFI on board. Just ripe for experimenting with. Not sure if I can get OpenWRT to run on those though. https://www.isee.biz/products/igep-processor-boards/igepv2-dm3730
Unless you want to cover an area larger than a single WIFI hop can reach or want multiple redundant routes for fault tolerance no special "mesh" software is required. I'm curious to see OSPF working over WIFI and doing it's automatic rerouting around failed nodes though.
Anyway, I'm stuck just now. After travelling to Ireland last week I come back to find my PC is totally dead. Won't even try to start....grrr...I hate computers.
Actually considering using the MR3020 for a wifi motorcycle alarm. When locked, the motorcycle won't start. When armed, the lights will blink, send an email, and the horn will beep if triggered for a period of time or silently just send email.
The nice features are that one could use a wifi device that they already carry to control the alarm, and one could remotely control the alarm in custom ways. If you actually see someone stealing the bike, you could intensify the alarm.
There is also the possibility of monitoring all sorts of engine functions via wifi.
Okay, on the MR3020 I am now in Chaos_Calmer (Bleeding edge r41945).
Good-bye to Attitude_Adjustment v12.09 and whatever (Yes, I skipped over Barrier_Breaker). It seems I lost LuCi, my pi-propeller-loader, USB FTDI driver, and other stuff.
So I will have to explore and reconfigure to get back up to where I once was.
Nonetheless, if anyone desires the same -- I did a compile for all AR71xx devices and related packages. That included the WR703 that Cluso is using, the MR3020 that I and Heater are using, and dozens more.
Feel free to ask for .zip file if someone wants these without having to compile themselves.
+++++++++++++++++
Please note -- OpenWrt seems to rotate its attention toward new routers. So as a device get older and less popular, the user has to maintain fresh compiles of binary firmware.
These AR71xx binaries are quite fresh and will allow you to do more. And the .zip includes a directory of fresh compiles of Packages.
I think "opkg update" and "opkg install luci" should get you Luci back again. You will need to configure it as per the instructions in the OpenWRT documentation as well though.
Zip file is not required as all those are available from nightly builds of trunk on downloads.openwrt.org
I think "opkg update" and "opkg install luci" should get you Luci back again. You will need to configure it as per the instructions in the OpenWRT documentation as well though.
Zip file is not required as all those are available from nightly builds of trunk on downloads.openwrt.org
Yep, after installing the new binary.... I need to first get opkg working with a good repository (at OpenWrt or Local), and then LuCi and all else will fall into place.
I was a bit surprised that my SSH configuration, the /etc/network, and the /etc/wireless remained the same. I had expected to have to start over from scratch.
+++++++++++
I guess Cluso wants me to post the zip of 'all and everything'. I did do the Zip, but it is huge... over 1 Gbyte. So I will have to downsize this to focus on WR703 and MR3020 firmware... and the related Packages directory.
Heater seems to mention that the Packages are recompiled nightly and available at OpenWrt, so that may be a waste of time.
opkg should just work. Have a look in /etc/opkg and check the URLs it has for fetching package files. There should be five or six of them pointing to nightly builds of trunk packages. You should be able to navigate to those directories with your browser and see the relevant files.
I was a bit surprised that my SSH configuration, the /etc/network, and the /etc/wireless remained the same. I had expected to have to start over from scratch.
That's interesting.
When I flashed the MR3020 with factory image I had built I was also surprised that my configuration had been preserved from the previous install and set up I did. In fact I thought things had gone horribly wrong because I could not find it at the IP address I expect of a clean install.
I almost convinced myself that I had accidentally flashed it with the sysupgrade image by mistake. Looking at the config files, sure enough they were as they were before.
So now, with your similar experience, I don't know what is going on or how it should actually work. I expect "factory" to blow everything away.
Loopy,
I am not ready yet - still doing fpga P1 in between other jobs. But I am following what you are both doing.
Ultimately I am going to need to build my own WRT and from what you have both done, I will start with Chaos Calmer.
A. The 'all and everything' zip is way too large for usual Parallax upload/download. Even if the 1Gbyte zip is accepted, you will have to tie up your machine and Parallax's servers for a long time to acquire.
B. Just posting the binary file without zipping or other modification hits a snag the the Forums download/upload limits. 4Mbytes is way over the limit.
This is just another one of those networking details that interrupts my progress.
I plan to create a couple of device specific zips. One for the WR703N and another for the MR3020. The zips can include the pi-propeller-loader for convenience. Some items would be still gotten from opkg (like the USB FTDI driver and LuCi).
So far the issue of opkg repository seems best handled by OpenWrt servers. Heater got that working, but I am having to learn a bit more about wget to resolve the URI path specification.
I have pretty much had an unstated goal of creating another thread entitled "The Propeller Wifi Programmer and Terminial interface" after I figured out all the details that I had gotten lost in.
The purpose of that would be just to deploy the WR703 or MR3020 as an independent Programmer and Serial Interface. Other possibilities are endless and pretty much vector one away from Propeller use and deep into Linux use.
Here are the Zip files for the WR703 and MR3020 binaries with pi-propeller-loader included and a bit of explanation. These are the Trunk images I mentioned above. Chaos_Calmer (Bleeding edge r41945)
Both are about 5.6Mbyte zip files.. so take some time to download.
I have also included a photo of my MR3020 opened up with the USB2SER attached.. just to give users an idea of what is possible. You do not have to open the device to program the Propeller if you have a USB2SER or a PropTool. The configuration is the photo is for recovery via FailSafe mode if you really mess up your OpenWRT configuration.
I will be pitching in a few dollars to help them get that off the ground.
If I purchased one of everything interesting that Kickstarter offered, I suspect my brain would explode before I got anything done.
I am really happy with my TP-Link MR-3020. I bought two of these and have yet to open the box on the second one.
I like the TP-Link MR-3020 as I have an enclosure, a power supply, and cables included. I will pass on the Black Swift.... too many irons in the fire as it is. In fact I am so busy with learning to use what I have that I am chatting less on the Parallax Forums.
But I must admit I am smitten by Anastasia Tarakanova.... quite the fair redhead beauty.
I can see how one could become a KickStarter "junkie". In fact checking the backers pages of Kickstarter it amazes me how many projects some people have backed.
And yes, I too have too many toys here to keep up with. Just can't resist the next interesting gadget.
But, Anastasia is about to get a hundred dollar backing from me:)
Comments
Apparently if you top off the file system, the Openwrt fails and you have to go into Failsafe mode to dump the extra files. Of course, if you provide a binary that consumes too much space, dumping via Failsafe may not work. You will have to recompile and provide a smaller image. Failsafe mode can also load a new binary. So you haven't bricked the MR3020. .... but you do need to access the RS232 Tx and Rx to navigate Failsafe mode.
For using the Serial Console via Tx and Rx...
If you have a cable for direct plug in to the Propeller and don't want to change it, you will have to create a tiny 'null modem' cable of 3 wires (GND, Tx, and Rx) that crosses over Tx and Rx. Then you can just use a PropPlug or USB2SER to get into the MR3020 at 115200 8N1 for Failsafe operations.
~~~~~~~~~~~~~~~~~~~~~~~~~~~
That pesky Reset problem...
I am satisfied that pi-propeller-load is working right, but there is something about GPIO to Reset configuration that is NOT 100% stable. My best solution is to disconnect it when not loading binaries.
I can set up the GPIO29 to export/out/high and reach Forth on the Propeller.
I then set four LEDs on i/o pins 1 to 4 to light and leave this to run.
When I come back in an hour or so, the LEDs are all out. This seems to indicate a Reset has been triggered.
Going into the MR3020 logs, the device seems to have NOT reset.
And checking the GPIO29 configuration still shows export/out/high.
So I am not sure of the source of the Reset or if measures that Heater applied to his D-Link are necessary.
++++++++++
For my own communications use, I find that having just the Tx and Rx connected to Forth on the Propeller to be rock solid stable. I can leave that for long-term wifi communications.
It is only when I desire to load binaries that I need the Reset.
In SUM, for a wireless programmer, the current setup is fine. Very feasible for a bunch of students sharing one wifi programmer in a classroom setting.
For wifi robotics, one may have to disconnect the Reset and just use the Tx and Rx. Forth isn't the only way to do this. There is interpreted Basic and one can write up their own serial interface. If one needs to reset the Propeller over wifi, one can create a 'reboot' command that will do so.
I am satisfied with what I have now. But Heater may want that Reset to be rock-solid. I am beginning to wonder if these SoC chips might occasionally poll and toggle all the export configured GPIO. I would have to set up a Propeller that monitors the Reset line and logs the time interval between resets to determine if they are regular or sporadic. I think that might settle the speculation on RFI causing resets or something in the SoC GPIO setup being the source.
I'm back to a fresh install on the MR3020. I was stuck, file system full, could not install 3G USB packages, could not uninstall Luci to make room. Stuffed up, no place to go.
But I was still logged in via SSH so thinking about it I just deleted a bunch of files that looked redundant for now, clearing up a bit of free space. Then hit the firmware "flash button" in Luci. It worked. Phew!
So now I back to a minimal OpenWRT install with lot's of free space.
The only thing I was thinking of reporting as a bug was that business of opkg not finding it's Package.gz file on line. But the new install, built fom latest sources, has fixed that anyway.
The "chaos calmer" thing was a surprise. It just happens to be what you get well you pull the latest sources from git.
@Loopy,
Yep. When the file system gets full all kind of stuff starts to to not work in odd ways. Luckily I managed to avoid any messing with fail safe mode this time.
According the the instructions on building OpenWrt if you try to buld a binary that is too big to fit your device it won't do it.
For sure I will be setting up a little cable to get serial connection via a Prop Plug. I always feel safer with a "back door" console connection.
Your random reset problem sounds very much like what I had. Any long wire hanging off the Propeller reset acts like an antenna and can pick up all kind of disturbances. Years ago I had such a set up and it used act as a very good "fridge monitor", it would reset whenever the refrigerator in the house turned on or off!
Adding the 10K pull up to reset, 10 or 100nF to ground and 100 ohms in series with that antenna fixed it for the D-LINK connection. But I'm still not sure if that is an optimal solution.
I don't agree with your conclusion. If what we have here is a hardware problem, sensitivity to external electrical disturbance, then that hardware problem should be addressed. Changing programming languages is not the solution.
There is a possibility that something in OpenWRT is hitting the GPIO unexpectedly, like it does with that blue LED on power up on my D-LINK. Unlikely but possible. If so we have to track it down and stop it.
I might just forget the issue 3G USB dongle configuration and put Luci back on the MR3020 for now. Better to get the Propeller link working first.
Well it seems I have to follow your agenda of tracking down the spurious Reset, or move on to my own desire to get the MR3020 to operate in STA mode as a stand alone wifi device.
I really can't do both at the same time. I do admit that I have an A/C right next to where the MR3020 is running and that could trigger a reset.
It is not that I am satisfied with the spurious reset issue. It is that I am satisfied with the idea of programing the Propeller through Forth and avoiding the problem altogether.
But the possiblilty of a spurious reset puts all GPIO uses into question... not just the Reset. The 4 LEDs I do have on the MR3020 seem to flicker at times. I will watch that in terms of what the A/C is doing when they flicker.
_________
I have to move on to filing my 2013 Income Tax, which is on an extended filing. So I am not going to spend as much time as I'd like with the MR3020 for a few weeks.
I will try some long-term LED test with the Reset/GPIO disconnected and see if I am satisfied with the stability.
Interesting about Chaos Calmer. That is the current development version thayt they hope to release around Xmas. The release version is in RC3 (the other day) and is B... B... (cannot recall ist name). This is all on the OpenWRT.org home page.
For the time being, if you can get by working around the reset problem, I will look at it later - having too much fun with the P1 FPGA atm. But I do have to get this running so I have to order some boards shortly.
I removed the Reset attached to GPIO29 from my Propeller and just used the Tx and Rx attached. The Propeller remains stable, no reset for more that 24 hours, whereas I was getting spurious resets within an hour when I had the GPIO29 connected to the Propeller's Reset.
It does seem to require a ground loop or a complete circuit to involve the spurious reset. I left the wire from the GPIO29 attached to the Propeller Reset, so there was the equivalent of an 8" antenna attached to the Propeller's Reset. That alone is not enough. This might explain why the 100pf capacitor to ground is helpful.
I can insert Heater's scheme to filter unwanted resets and see how that works.
But the point is there are two alternatives -- [a] do without a Reset after programming, add circuitry to stabilize the Reset.
+++++++++++++
I still haven't perfected a configuration for wifi only, without a LAN connection. But it seems that should be easy.
I wanted my MR3020 to act as an autonomous programmer and communications device with the Propeller. Heater suggested I reconfigure to STA mode from AP mode for that. But I spent quite a bit of time with this not seeming to work.
It now seems that you have to use a Trunk firmware image to have STA included as an alternative in the firmware, maybe not available in Attitude Adjustment v12.09.
IOW, there is a lot that one has to learn about the OpenWrt way to become creative with it.
Here is a snippette from the Wireless Configuration HTML that seems to point the way. I guess I have to compile and load a fresh firmware image to have all and everything to play with.
'mac80211 STA mode supported on trunk. STA and AP at the same time is not yet
supported(r22989).'
I have been away from home most of the week so I had little chance to get on the net and check the action here.
Whether you use your WIFI as a station or access point is somewhat independent of whether you are using the unit as a Prop programmer or not.
I just imagined that one might have many units around the house, or boat it Cluso's case, in which case having them as stations connecting to a central access point is probably what you want to do.
I think you should just bite the bullet and check out the OpenWRT sources from trunk and build your own image. Then you also have the tool chain ready for building the loader or anything else you want to do.
Having your own sources means you can easily build an image for some other platform you get hold of. Like that Raspberry Pi you are itching to try out
My real problem was not catching in the OpenWrt on-line documents that a STA mode required such.
I started out with Attitude Adjustment V12.09 because of all sorts of warnings about the stability of images compiled from Trunk. But it seems that one can only go so far with a conservative approach. And in my case, I got stuck with every reconfiguration to STA mode shutting me out of the MR3020.
And so, I will recompile (there is a GIT repository) and load a latest Trunk image. From there, I should be able to get STA mode, and quite a few other features. Of course, like Heater, I may have to get my packages from elsewhere -- so it is a good idea to compile all those for yourself at the same time.
So, I am just making sure others understand how to get the most out of OpenWrt. Aptitude Adjustment and Barrier Breaker may really just be for those that want to have a stable custom router. Here, we are getting out into more creative things. I also see that Trunk in required if there is a desire to build a Mesh network of wifi... that also appeals to me.
Itching to try Raspberry Pi? Well........
I would not worry about packages when using trunk. I found that my build of trunk from sources ends up fetching packages from snapshots of trunk that seem to be built everyday from the latest sources. Here: https://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/
Of course things can go wrong with software under development. For example for a few days I could not load any packages as the trunk version of opkg was configured wrongly out of the box. But hey, we are all hackers here aren't we?
I was getting curious about the mesh idea the other day. Turns out we have a dozen or so ISEE IGEP boards in the office that may never be used. Like Beagles only better. They all have WIFI on board. Just ripe for experimenting with. Not sure if I can get OpenWRT to run on those though. https://www.isee.biz/products/igep-processor-boards/igepv2-dm3730
Unless you want to cover an area larger than a single WIFI hop can reach or want multiple redundant routes for fault tolerance no special "mesh" software is required. I'm curious to see OSPF working over WIFI and doing it's automatic rerouting around failed nodes though.
Anyway, I'm stuck just now. After travelling to Ireland last week I come back to find my PC is totally dead. Won't even try to start....grrr...I hate computers.
The nice features are that one could use a wifi device that they already carry to control the alarm, and one could remotely control the alarm in custom ways. If you actually see someone stealing the bike, you could intensify the alarm.
There is also the possibility of monitoring all sorts of engine functions via wifi.
Good-bye to Attitude_Adjustment v12.09 and whatever (Yes, I skipped over Barrier_Breaker). It seems I lost LuCi, my pi-propeller-loader, USB FTDI driver, and other stuff.
So I will have to explore and reconfigure to get back up to where I once was.
Nonetheless, if anyone desires the same -- I did a compile for all AR71xx devices and related packages. That included the WR703 that Cluso is using, the MR3020 that I and Heater are using, and dozens more.
Feel free to ask for .zip file if someone wants these without having to compile themselves.
+++++++++++++++++
Please note -- OpenWrt seems to rotate its attention toward new routers. So as a device get older and less popular, the user has to maintain fresh compiles of binary firmware.
These AR71xx binaries are quite fresh and will allow you to do more. And the .zip includes a directory of fresh compiles of Packages.
Zip file is not required as all those are available from nightly builds of trunk on downloads.openwrt.org
Yep, after installing the new binary.... I need to first get opkg working with a good repository (at OpenWrt or Local), and then LuCi and all else will fall into place.
I was a bit surprised that my SSH configuration, the /etc/network, and the /etc/wireless remained the same. I had expected to have to start over from scratch.
+++++++++++
I guess Cluso wants me to post the zip of 'all and everything'. I did do the Zip, but it is huge... over 1 Gbyte. So I will have to downsize this to focus on WR703 and MR3020 firmware... and the related Packages directory.
Heater seems to mention that the Packages are recompiled nightly and available at OpenWrt, so that may be a waste of time.
I'll generate a limited Zip and post.
opkg should just work. Have a look in /etc/opkg and check the URLs it has for fetching package files. There should be five or six of them pointing to nightly builds of trunk packages. You should be able to navigate to those directories with your browser and see the relevant files.
That's interesting.
When I flashed the MR3020 with factory image I had built I was also surprised that my configuration had been preserved from the previous install and set up I did. In fact I thought things had gone horribly wrong because I could not find it at the IP address I expect of a clean install.
I almost convinced myself that I had accidentally flashed it with the sysupgrade image by mistake. Looking at the config files, sure enough they were as they were before.
So now, with your similar experience, I don't know what is going on or how it should actually work. I expect "factory" to blow everything away.
I am not ready yet - still doing fpga P1 in between other jobs. But I am following what you are both doing.
Ultimately I am going to need to build my own WRT and from what you have both done, I will start with Chaos Calmer.
The situation this:
A. The 'all and everything' zip is way too large for usual Parallax upload/download. Even if the 1Gbyte zip is accepted, you will have to tie up your machine and Parallax's servers for a long time to acquire.
B. Just posting the binary file without zipping or other modification hits a snag the the Forums download/upload limits. 4Mbytes is way over the limit.
This is just another one of those networking details that interrupts my progress.
I plan to create a couple of device specific zips. One for the WR703N and another for the MR3020. The zips can include the pi-propeller-loader for convenience. Some items would be still gotten from opkg (like the USB FTDI driver and LuCi).
So far the issue of opkg repository seems best handled by OpenWrt servers. Heater got that working, but I am having to learn a bit more about wget to resolve the URI path specification.
I have pretty much had an unstated goal of creating another thread entitled "The Propeller Wifi Programmer and Terminial interface" after I figured out all the details that I had gotten lost in.
The purpose of that would be just to deploy the WR703 or MR3020 as an independent Programmer and Serial Interface. Other possibilities are endless and pretty much vector one away from Propeller use and deep into Linux use.
Both are about 5.6Mbyte zip files.. so take some time to download.
I have also included a photo of my MR3020 opened up with the USB2SER attached.. just to give users an idea of what is possible. You do not have to open the device to program the Propeller if you have a USB2SER or a PropTool. The configuration is the photo is for recovery via FailSafe mode if you really mess up your OpenWRT configuration.
Did you catch the announcement of the "Black Swift" tiny OpenWRT computer for 25 dollars?
I think we are all set to use that with the Propeller.
https://www.kickstarter.com/projects/1133560316/black-swift-tiny-wireless-computer
I will be pitching in a few dollars to help them get that off the ground.
If I purchased one of everything interesting that Kickstarter offered, I suspect my brain would explode before I got anything done.
I am really happy with my TP-Link MR-3020. I bought two of these and have yet to open the box on the second one.
I like the TP-Link MR-3020 as I have an enclosure, a power supply, and cables included. I will pass on the Black Swift.... too many irons in the fire as it is. In fact I am so busy with learning to use what I have that I am chatting less on the Parallax Forums.
But I must admit I am smitten by Anastasia Tarakanova.... quite the fair redhead beauty.
Very sensible.
I can see how one could become a KickStarter "junkie". In fact checking the backers pages of Kickstarter it amazes me how many projects some people have backed.
And yes, I too have too many toys here to keep up with. Just can't resist the next interesting gadget.
But, Anastasia is about to get a hundred dollar backing from me:)