Forum Replies Created
-
AuthorPosts
-
uRADMonitor
KeymasterI think you’re right Ben. And this makes it strange: to get inconsistent behaviour depending on the network!
I have a router that I know was causing some problems with uRADMonitor units. I’ll need to find it and run some tests before I can report back.
The DHCP code was mainly written by me, and in the last revision I added the hostname option (in the form uRADMonitor-
). Previously you would only see the MAC, the allocated IP and no hostname. I might have done something wrong so hopefully things will clarify. Another option is checking it against the Arduino implementation, but I find that complicated with all the Arduino libs and custom I/O code.
uRADMonitor
KeymasterSounds great! And nice work
uRADMonitor
KeymasterLooks great, Peter! Congrats on the nice installation.
uRADMonitor
KeymasterThe 02…. are locally administered addresses. Nothing special about them just that they are free. To register universal administered addresses I will have to pay some money. I will do that in the future.
Vinz, are you getting the same issues with DHCP? can you post more details?
In my local tests, DHCP was fine, so it’s a bit hard for me to replicate this for a fix:
Attachments:
uRADMonitor
KeymasterI’m afraid there were no updates. So the change must have been local. Yes, currently there are several IP used. The one for data is correct: 23.239.13.18.
Lars, just as a note, I don’t think this is physical, nevertheless if you are unable to find the problem, you can send the unit back anytime to get a replacement.
uRADMonitor
KeymasterHello Vinz,
I think you have covered pretty much everything to secure the problem and even beyond that to detect if a device is behaving suspicious.
Also @Jeff ‘s suggestion on checking upload interval is important in limiting invalid data.
Unless anyone has anything else to add, I will propose this as solution, and standardise it in a specs document written for the next firmware release.
uRADMonitor
KeymasterIndeed patching would automate the production of unique firmware binaries, without compiling the source code every time.
But there is also the approach presented here: https://www.uradmonitor.com/topic/automated-device-ids/
The eeprom can also be written without changing the firmware using a separate script, after main firmware is written.
uRADMonitor
KeymasterVery good ideas, I find the one with the favourite station particularly useful.
uRADMonitor
KeymasterI’d say yes, it seems a useful thing to have, although my experience with Wiki is limited.
uRADMonitor
Keymasterhighcarts.com looks interesting, I will check it out in more detail.
@vinz, would you post the link to your implementation here?uRADMonitor
KeymasterI love this idea. Clean and efficient!
uRADMonitor
KeymasterYes, this makes sense. Regarding 2) what would be the memory requirements on the linux box?
-
This reply was modified 11 years, 4 months ago by
uRADMonitor.
uRADMonitor
KeymasterThe first uRADMonitor devices used the mega168, but the project grew in complexity so the upgrade was natural.
I was wondering if it would be possible to integrate OTA, using an exotic technique: having the code run in the first 16KB section of flash (offset 0), download the new firmware in the second section (offset 16K), than move new firmware block to offset 0 when download is ready. This might require a bootloader. I wonder if its possible to do it without one?
Anyone has any experience with this?
uRADMonitor
KeymasterWith the current hardware, OTA updates are impossible. Those interested in updating will have to do it manually. It is not complicated at all, but requires physical access to device’s PCB board and a USBAsp programmer
(http://www.ebay.com/itm/171505112768)uRADMonitor
KeymasterA cron script to compute average/month, ran once per month?
Probably this can be taken further: the cron script would compute the average for last month, and move all previous month rows to “archive” db.
However some people would like to “go back in time” and analyse data: say there is a spike that happened two months ago on a given station. One might want to check the data including “zooming” to see max resolution data to understand the phenomenon better. Then move to other stations nearby to check for the same thing.
I wonder how this scenario could be implemented efficiently.
There is one row/device/minute added to the db constantly.
-
AuthorPosts
