THE STORY OF INTAQO

5.10.2017

We have decided to deepen the cooperation with the DPSK Company who produced for us the first generation of PCBs. We have ordered a design modification, which will have the following changes:

  • Problem with 24V power supply
  • Resolution of potential problem with PAR sensor connection. Basically redesign of the PAR sensor connection, because we have seen 2.8V where the expected maximum was 1.0V
  • Modification of the temperature sensor connection. Change of used PIN on the ESP.
  • Change of connectors from 5/2.5 to 5/2.1 barrel jacks
  • Change of physical connector for temperature sensor to 2.5 mm audio jack. So we will use 2.5mm jack for temperature sensor and 3.5mm audio jack for PAR sensor.
27.9.2017

Finally, I am receiving comits in GIThub for the mobile application from 2 of the developers. Unfortunately, these are still early stages of development with no visuals to share yet.

23.9.2017

We discovered that the temperature sensor is not working. For some reason, it is not answering on the dedicated bus on the ESP. We probably have the electronic setup wrong. Need to investigate further.

20.9.2017

JT is the torchbearer of the project. He is making great progress in understanding the HW problem with 24V and implementing new features in the Firmware at the same time. The HW problem solution has to do with Schottky diods – “The maximum reverse voltage rating of the Schottky diode should be greater than the maximum input voltage, and the current rating should be greater than the maximum load current.” I have no clue, but JT is already making modifications to the PCB and is quite optimistic about fixing the problem.

On the Firmware front, he has solved the preflight options problem:

  • Added support for HTTP preflight requests (OPTIONS) to following methods: /wifiConfig, /exitConfigMode, /deviceInfo, /wifiState and /wifiScan
18.9.2017

Today, we finally confirmed, that the boards are not able to work under 24V. JT had tested one board and had fried it in the night. This is quite a blow, as the board ought to be designed not only to work with 24V but also have protection for overcurrent.

Also, I received first version of application from Praboda. At first, it seemed the app has correctly implemented SSDP protocol, but then I discovered it was hard-wired to work with the APIARY backend with mock APIS.

🙁 Another tough day.

16.9.2017

JT is making phenomenal progress!

  • Added first API method to work in AP mode to setup Wifi
  • Not found handler moved to separate function (to be able to call registerHandlers() within WifiManager)
  • Attempt to join request handlers of WifiManager and RMLD. It does not work, because WifiManager does not see methods of RMLD.
  • ESP-07 module on 1st PCB series requires “Generic ESP8266 Module” settings in Arduino IDE. Therefore mapping of named PINS (D0, D1, …) was added to code (it is not available in generic board definition). Mapping was reused from Wemos D1 mapping. REVERSE_INTENSITY_CONTROL set to true to match 1st series behavior, LED_BUILTIN is on D4.
  • ESP-07 module on 1st PCB series “Generic ESP8266 Module” settings in Arduino IDE.
  • Added support for AP mode operation. Added API to configure WiFi settings
  • Added WiFi configuration related methods to get WiFi connection status and to scan WiFi networks

I just wish the mobile application stream of the project was as good as this. Unfortunately, none of the freelancers had shown the so much expected qualities so far… 🙁

13.9.2017

In the meantime, JT was busy with trying the boards work. We experienced great difficulties, as the firmware we were using on the prototype boards did not work on the produced PCBs. After a lot of effort, we understood that there is a difference in the ESP modules used. The prototype has module ESP8266 12s with 4MB of memory and the boards have ESP8266 07 with 1MB of memory.

This means that JT had to do some refactoring to make sure the compiled firmware is less than 0,5MB.

Luckily enough, JT is a genius and he managed to do it and we have the very first RMLD board working 🙂

It works nicely with our prototype application made in APP INVENTOR, so I am able to manage the LED lights

Today JT discovered that there is a HTTPS server implementation for ESP32, but there is none for ESP8266. This leads us to thoughts about upgrading the chip in the next HW revision.

12.9.2017

We have discovered a serious problem that could threaten the whole project.

Apple announced that it will not allow any application to communicate with APIs that are not secured with SSL certificate.

The problems are 2:

  1. There is no implementation of HTTPS server for ESP8266
  2. Even if there was, this means, that we will have to put a valid signed certificate on every device and maintain it over time

For now, we have no clue about how to solve this problem.

11.9.2017

I have decided to start working with 7 freelances and to choose after delivery of the DEMO app who to continue working with.

  • Susanna H. (Yerevan, Armenia),
  • Satveer S. (Sangrur, India),
  • Abdul M. (Lahore, Pakistan), 
  • Praboda M. (Kamburugamuwa, Sri Lanka),
  • Sergey M. (Kiev, Ukraine), 
  • Sayem S. (Dhaka, Bangladesh),
  • J Prethi S. (Coimbatore, India)

 

It looks like our team is going to be even more multinational J

I hope to have a decision on the right colleague within a week!

9.9.2017

Wow! I have received 62 responses to my job posting. It is quite difficult to make a decision based only on the responses and the previous applicants’ work.

I have made an update of the job description:

Update – specification attached

  

Hello,

Thank you for applying to my project.

I want to find a developer for long-term relationship and I came up with the following way how to choose.

Attached please find a specification of an application, which I really need to get done (DEMO APP). It will serve for certification of the HW that the final app should work with.

I will award this project to several developers (and pay for it) to see the quality of their work.

For the final application development I will choose the developer who I find best (based on quality of code, communication, understanding, …)

Requirements (and criteria for selection) for the project are the following:

– Develop the app based on the specification

– Clean, commented code

– No design required (style to be applied separately – all elements need to be correctly tagged)

– Use Cordova (ionic or similar can be used)

– Use GIT (I will provide access to my github project)

– Use JIRA for testing & fixing (I will provide access to my jira)

– Use Slack for communication

– I will need to help to build the application locally and test it with the device

– Mock APIs will be available for your perusal in apiary.io

If you are interested, please give me a fix price offer for development of the DEMO APP based on these criteria.

Or please ask for any details that you feel are missing in order to give a fixed price offer.

Thank you very much,

Jan

 

Included was a document with a specification of a demo application we plan to use for the HW certificaiton. If anyone is interested, drop me an email and I can share the details.