Forum Replies Created

Log In Register Lost Password
Viewing 15 posts - 751 through 765 (of 766 total)
1 2 3 … 50 51 52
  • Author
    Posts
  • December 9, 2014 at 5:40 pm in reply to: Firmware upgrade #776
    Radu
    Keymaster

    The 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?

    December 9, 2014 at 4:51 pm in reply to: Plans for the network – data access #774
    Radu
    Keymaster

    With 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)

    December 9, 2014 at 4:49 pm in reply to: Database optimisations #773
    Radu
    Keymaster

    A 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.

    December 8, 2014 at 10:25 pm in reply to: Android/iOS App #743
    Radu
    Keymaster

    Great initiative.

    I think one useful feature will be to automatically show on app startup all stations close to user’s position, so the app would be as informative as possible. Also stats on radiation trends and a few lines on exposure limits and their effects, as published in current literature.

    Email alerts or push notifications should be configured on the website, and delivered to the mobile apps, for events like: major changes in background radiation levels at some location, preconfigured threshold reached, etc.

    The ui should take advantage of modern UI/UX

    Attachments:

    1. gfx-1-copy.jpg

    2. gfx-2-copy.jpg

    December 8, 2014 at 6:50 pm in reply to: Extend the maps #737
    Radu
    Keymaster

    I think this idea was first formulated by Peter ( https://www.uradmonitor.com/?open=11000026 ) . What he said was to add an overlay with the nuclear plants on the uRADMonitor map, with a descriptive icon. To this I would add the option of having a switch, to toggle such overlay on/off.

    The good thing here is such information is publicly available: http://en.wikipedia.org/wiki/List_of_power_stations_in_Germany (this is an example for Germany).

    We only need to build a list with Name, country, city and GPS coordinates and this can be easily integrated.

    December 8, 2014 at 6:41 pm in reply to: opening Development section? #736
    Radu
    Keymaster

    ok, consider it done.

    December 7, 2014 at 10:23 pm in reply to: Plans for the network – data access #717
    Radu
    Keymaster

    Hi Richard!

    There was some very good progress with an updated firmware which opens port 80 on the unit, so you can connect to it via your browser in the local network. As soon as it is ready and it passes all stability tests, it will be released and available for update. The idea with this is to break the dependancy to the central server: in case something bad happens and the server goes down, you’ll be able to access the unit’s measurements directly in your local network, using only the Internet Browser.

    December 7, 2014 at 10:20 pm in reply to: more than one central-server? #716
    Radu
    Keymaster

    So if I understand it correctly, this could be packed into the following scenario:
    1) By default program the units with a default mac, a default ID and uradmonitor.com as single server
    2) When the unit connects, it would download a freshly allocated mac/device ID and a list of alternative servers and store the data in its EEPROM.
    3) Periodically, the unit would check if other alternative servers are available (and delete those that are offline).

    Would this work? Does it cover everything, enough to make this decentralisation stand?

    I believe the logic will require only a minimal code, that can fit in the available flash memory. The only issue is I find multiple transmissions of the same data to multiple servers a bit redundant (not a big issue though).

    December 7, 2014 at 6:31 pm in reply to: Automated Dynamic ID allocation #704
    Radu
    Keymaster

    Hmm…this is an excellent idea! I can’t find a scenario to invalidate it yet. But let’s think it through.

    December 7, 2014 at 5:49 pm in reply to: more than one central-server? #700
    Radu
    Keymaster

    My pleasure. The “connection-watchdog” is set to 5 minutes.

    December 7, 2014 at 5:47 pm in reply to: Introduce Yourself! #699
    Radu
    Keymaster

    Hi all,

    I’m Radu, I live in Timisoara, Romania. I was trained as a software developer, been doing that for a few years now, focusing mostly on mobile development. Hobby brings me close to electronics and physics.

    December 7, 2014 at 5:34 pm in reply to: more than one central-server? #694
    Radu
    Keymaster

    These are all valid points, Vinz, and we should see how to secure the central server dependancy.

    But at least for the IP, things are not that bad:
    – the units use DNS to resolve data.uradmonitor.com to latest IP
    – if communication fails, the units will automatically reboot, part of a watchdog mechanism, so at least this part is covered.

    As you said it is a good time to start thinking about a way “to break the dependency to the central server”, while keeping the solution easy to use (plug and play)

    December 7, 2014 at 2:18 pm in reply to: Firmware upgrade #688
    Radu
    Keymaster

    It sure does! 🙂 The risk is there, alright. The hardware is the problem, it just doesn’t have enough memory to store the download, and then replace the current firmware, like it’s done with other OTA updates.

    The microcontrollers used are the atmega328p, with 32K of flash, 2KB ram and 1KB eeprom.

    The binary firmware is currently getting close to 14KB.

    I guess some will be able to update the firmware, while some will only be able to continue using the stock one.

    December 7, 2014 at 11:05 am in reply to: Database optimisations #678
    Radu
    Keymaster

    Currently there is a single database for both development and production. There are two tables, one is devices and the other is uradmonitor.

    t1) devices
    Has a single row / uRADMonitor detector, the primary key is the device id. It holds only the latest readings, the 24h average for radiation (as CPM) , the detected location, the overridden location , country code and offline/online status (considered offline if no data received for more than 10minutes).
    As we speak this has 116rows and uses a little over 12KB.

    t2) uradmonitor
    This now has 7,4 million rows and a size of 432MB.
    Each unit in the network sends data via a HTTP Get call to the data.uradmonitor.com . The parameters include the unit ID, measurements and a CRC. All this data gets into the database.
    So each minute, one station send aprox. 58Bytes of data to the server.
    The problem is we got quickly from one unit to ten, and we are now approaching 100 units.
    Probably we’ll need to archive some of the old data. Would be nice to find a way to do it automatically, to get faster DB queries on the fresh data, but for scientific purposes to allow slower queries but on ALL the data.

    December 7, 2014 at 10:40 am in reply to: Security: invalid data injection #676
    Radu
    Keymaster

    Delay check might help at least to exclude packets coming too early, so we could have this among other mechanisms.

    PKI would be excellent, but probably impossible for the reasons you’ve mentioned, but also because it requires a relatively complex code, and the available memory is low.

    We also need to think of a solution as close to plug-and-play as possible. If it’s too hard to implement on DIY units, it will not work.

  • Author
    Posts
Log In Register Lost Password
Viewing 15 posts - 751 through 765 (of 766 total)
1 2 3 … 50 51 52