Lightning shutter trigger 2.0 - another picture

flashYesterday, we got a thunderstorm. Usually, when people are on vacation, they prefer a nice weather. This is not the case for us Smile. We took the car, and drove to a place a few kilometers southwest of Ancelle, the small village where we are staying for a week, in south of french Alps.

Our flash detector triggered several times, but we got only two pictures. Only one displays a flash. The other one was triggered by a distant intra-cloud lightning, and it's hardly visible on the picture. Other detections came from flashes in our back (yes!) or on our sides. Conclusion: I'm happy with sensitivity of this version of the trigger Smile.

Playing with Play - 2

playMain concepts (for Scala)

Keypoints of Main concepts for Scala page.

HTTP programming

An Action handles a Request and generates a Result.

A Controller is an object that generates Action values.

The built-in router translates each incoming request to an Action. Routes are defined in conf/routes. Each route is defined by three parts:

  • HTTP method
  • URI pattern
  • call definition

Lightning shutter trigger 2.0 - first pictures

flashToday, with my youngest son, we were able to test in real conditions the new version of the lightning shutter trigger, thanks to a thunderstorm which appeared in the beginning of the afternoon.

The idea was not to spend time on picture quality, but just to check trigger sensitivity. And the results are good: every lightning flash was detected, even two ones that happened in our back and one that we did not see! Additionally, I realized that there is no need for an opamp in the circuit: for every picture, the trigger sets itself in non amplified mode (I implemented an automatic switch between amplified and non amplified mode).

Open source web conferencing solutions

Looking for an open source (video) conferencing solution. First links:

IoT tips and tricks - 1

As I wrote in a previous article, one of the distinctive features of IoT projects is that they require integration of technical blocks originating from three different domains: electronics, communications and software. And inside these three domains, various different subdomains are usually involved: analog and digital electronics, wireless communication modules, protocol stacks, embedded software, user interfaces, database management, analytics, geospatial data, etc.

Therefore, when developing a new system, it's almost impossible to only rely on technical blocks developed in-house, or that you have been already using for a long period: you have to integrate some new components provided externally. And usually you'll discover that provided documentation does not say everything about components characteristics and behaviour.


Subscribe to Front page feed