Forum Replies Created

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • in reply to: How to detect and act on an incident ? #1558
    Ally
    Participant

    I agree with Wiretap – IFTTT integration would be fantastic feature for the network. I’ve thought about this before.

    When the network detects “global meltdown” I want to be able to have it automatically adjust my Nest Thermostat on my Air Conditioning to something more comfortable 🙂

    in reply to: Chernobyl in my Basement #1517
    Ally
    Participant

    I put it back outside. It continued to measure ~15 cpm for 40 minutes or so, then dropped back to its usual 6-7.

    in reply to: New servers #919
    Ally
    Participant

    Fantastic news! Count me in.

    in reply to: Security: invalid data injection #822
    Ally
    Participant

    Vinz, Datawarehouse time! Slightly off topic, but;

    Example: You could now use one new user for online requests (SELECT) only.
    If you limit this user, the database will always be able to store new data.

    Two databases, preferably on different servers, one – the OLTP system (datawarehousing speak: on-line transactional processing) database is where the monitors send their data. Not normally queried.

    Second database is an OLAP (on-line analytical processing) db. Is used for reads/queries. Can be kept near-real time with the OLTP db through clever data shuffling ETL processes.

    Disadvantage is you double your data, bonus is warehouse can be denormalised for speed, can be a history too – if need be, can truncate OLTP tables and still have all data from all time in OLAP warehouse. Also solves problem of read/write contention or query deadlock.

    Sounds like overkill in a project so ‘small’ but it’s growing very quickly and soon we’ll have to consider technologies like this, I think.

    in reply to: Database optimisations #820
    Ally
    Participant

    I was thinking of mentioning Hadoop/MapReduce or Cassandra, but these technologies are a big change from Radu’s current implementation, and the learning curve is steep.

    Very cool technology though. At my work I design/maintain a 500 gigabyte SQL Server data warehouse with almost 400 tables in a denormalised star schema – have been trying to get my bosses to look at hadoop and MapReduce, but it’s ‘new’ tech and therefore complex and scary 🙂

    • This reply was modified 9 years, 4 months ago by Ally. Reason: Spelling and grammar corrections. Fat fingers
    in reply to: uRADMonitor Wiki #797
    Ally
    Participant

    Likewise.

    Anyone know anything about MediaWiki, or any of the thousands of other Wikis?

    in reply to: Android/iOS App #762
    Ally
    Participant

    Love the example screenshots! Here’s a few things I’ve been thinking of – I’m not really considering feasibility right now – just throwing ideas out there into the pot.

    • Ability to search for units by ID, geographic location, etc – and to filter/order a list by CPM/dose rate/uSv/h, etc
    • I’d like the permissions of the app to be constrained to only those that are really necessary. The number of apps now that ask for full access to your camera, contacts, microphone, etc is shocking. Hopefully we can design it in such a way to be minimally intrusive.
    • IFTTT (https://play.google.com/store/apps/details?id=com.ifttt.ifttt&hl=en) integration – the ability to chain alerts into other Channels might be useful. For example; if my monitor registers CPM above a pre-defined threshold, email Radhoo and say “goodbye, nice knowing you”, etc.
    • Ability to set a favourite station, or stations, which will appear in your ‘dashboard’ or stats, without having to go into a list or map view to find them. For example, I could favourite or ‘star’ the three Orlando units – and would see their information together in one place thereafter, without searching for those units.
    • This reply was modified 9 years, 4 months ago by Ally.
    in reply to: more than one central-server? #761
    Ally
    Participant

    Ah, good point – you’re absolute right. I’d overlooked that; some way for the offline server to ‘catch up’ with the online ones.

    in reply to: more than one central-server? #759
    Ally
    Participant

    Hi Tim,

    Yes, you’re correct, the db is MySQL. There are currently two tables – Radu explains;

    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.

    When I mentioned replication I was thinking of doing it at the software level, some sort of ETL task to shuffle the data around and keep all the server/db’s in sync – but Radu suggested (I think) that the units themselves send their data to multiple servers. There would be some duplication of network traffic, but definitely a cleaner option.

    in reply to: Extend the maps #733
    Ally
    Participant

    Here’s a list of civil Nuclear power stations worldwide, from IAEA data, but not sure how recently it’s been updated.

    https://www.google.com/fusiontables/DataSource?dsrcid=579353#rows:id=1

    And here’s a list of civil facilities in the USA licenced to handle radioactive material – Uranium mine/mills, reclamation, etc;

    http://www.nrc.gov/info-finder/materials/

    • This reply was modified 9 years, 4 months ago by Ally.
    • This reply was modified 9 years, 4 months ago by Ally.
    in reply to: Extend the maps #730
    Ally
    Participant

    I think that’s a great idea. There must be lists of locations somewhere – the civil ones anyway. The military ones might be harder to plot – but we could plot the main ones manually.

    In the UK for instance, all nuclear weapons are stored in Scotland, just outside Glasgow, the largest city (as far away from London as possible!) at a place called RNAD Coulport (Royal Naval Armament Depot Coulport).

    Wikipedia has a huge list of all the civil ones from International Atomic Agency data, but they don’t have coordinates for plotting a map. Google time!

    There are some pretty good mapping products/overlays for Google maps that allow categories of locations, searching by location, filtering, etc.

    • This reply was modified 9 years, 4 months ago by Ally.
    in reply to: more than one central-server? #723
    Ally
    Participant

    I think your scenario works, Radu. However, I think the unit would still have to connect to a single point to retrieve the list of alternate servers, is that correct?

    In Vinz’s suggestion, there’s the option to point your unit at another server manually, so if the unit can’t retrieve the list from the central server, you could get a list of alternatives from Facebook, Twitter, email, etc etc and manually point at it. That sounds pretty useful.

    I don’t know how to deal with the initial allocation of the mac/device id in that scenario though.

    in reply to: more than one central-server? #707
    Ally
    Participant

    Hi guys,

    Yes, I agree with you both – the decentralisation of the single server model shshould be in our top 10 priorities. To defend against everything from hardware failure to malicious attacks.

    How about if duplicate servers were hosted by trusted volunteers – the units could send data to the primary server until it becomes unreachable, then would send to a secondary, then the tertiary server if the secondary fails, etc. We’d have to write some form of data replication (as close to real-time as possible) to keep all the servers in sync with each other – so when primary comes back online it receives the data collected by the secondary, etc. There are definitely better solutions, but I do it this way for a cluster of servers at my work, and it definitely works.

    • This reply was modified 9 years, 4 months ago by Ally.
    in reply to: Firmware upgrade #684
    Ally
    Participant

    You mention that OTA update is not possible in the current firmware. Are OTA updates possible in future firmware releases?

    I’m sure a lot of us have some experience of circuit boards, flashing firmware, etc, but there could equally be just as many people afraid to brick their unit by opening it up. And anyway, doesn’t opening it up void the warranty? 😉

    in reply to: Database optimisations #683
    Ally
    Participant

    Radu, on table 2 is there a timestamp for when new rows are inserted to the table?

    There are some good open source ETL tools I’ve been looking I to which would allow us to easily, and automatically, archive off rows from t2 into an archive table. This table wouldn’t be queried under normal circumstances I guess, but would be available if there was a need to see the whole history of a unit.

    For all the tables, we need to make sure they’re properly indexed and partitioned to optimise query speed – I’m not sure what options MySQL provides for that, will need to look into that.

Viewing 15 posts - 1 through 15 (of 15 total)