Forum Replies Created
-
AuthorPosts
-
uRADMonitorKeymaster
I 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.
uRADMonitorKeymasterSounds great! And nice work
uRADMonitorKeymasterLooks great, Peter! Congrats on the nice installation.
uRADMonitorKeymasterThe 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:
uRADMonitorKeymasterI’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.
uRADMonitorKeymasterHello 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.
uRADMonitorKeymasterIndeed 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.
uRADMonitorKeymasterVery good ideas, I find the one with the favourite station particularly useful.
uRADMonitorKeymasterI’d say yes, it seems a useful thing to have, although my experience with Wiki is limited.
uRADMonitorKeymasterhighcarts.com looks interesting, I will check it out in more detail.
@vinz, would you post the link to your implementation here?uRADMonitorKeymasterI love this idea. Clean and efficient!
uRADMonitorKeymasterYes, this makes sense. Regarding 2) what would be the memory requirements on the linux box?
- This reply was modified 9 years, 10 months ago by uRADMonitor.
uRADMonitorKeymasterThe 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?
uRADMonitorKeymasterWith 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)uRADMonitorKeymasterA 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