We are not involved in the Misty 2 project and we have no knowledge about it. For questions about Misty 2, please contact its makers. Having said that, all files are downloaded in the same way from GitHub. There is no special method for downloading javascript files. I suppose you are talking about the sample code? If you clone (or download) the Misty 2 SampleCode repository using one of the methods presented in the article/video above and you should get it all. If the code is in two different repositories, then you will have to clone or download them both.

I assembled and tested the hardware part. The main components required are:   -ATmega328P MCU      x1 pc -SD card and holder     x2 pcs -74HC125   buffer         x2 pcs -74HC86    XOR gate     x1 pc -74HC393    latch          x1 pc -32MHz    XTAL              x1 pc The basic idea is to make a direct DMA transfer of data between SD1 and SD2, by clocking them at 32MHz, through IC5C gate ("/f" gate signal). 74HC393 (double 4-bit counter) divides the 32MHz to 8MHz for the MCU clock. MCU gives SPI commands to both SD cards and then reroutes the data chunks through 74HC125 gates directly from SD1 to SD2, at 32 MHz SPI clock. The hardware part is tested completely, the DMA at 32MHz works well.For fast DMA copying (err... "fast" meaning faster than USB 1.1 :) the SCK is passed through IC7B and IC7A - the R25-R3-R2-C8-C6 network is adjusted to create a 30ns delay between SCK and SCK2 - an SCK pulse first needs to pass through IC5D, for a data bit to appear on pin 7 of SD1, then it needs to pass through IC5C and arrive to pin2 of SD2, so SCK2 needs to be properly delayed for this to work. For DMA verification/comparison between SD1 and SD2, the SCK is passed through IC7C, so SCK1 and SCK2 are equally delayed related to SCK - the data bits on pin 7 of SD1 and SD2 will appear almost simultaneously and arrive to XOR gate IC3A. If the two bits are different, the output of IC3A will go high and QA output of IC6A will latch. It will be kept high long enough for the slow MCU to read it (through PC0 input ) at the end of the data "chunk" - both IC3A inputs will staylocked high through D5 and D6, so no more triggering pulses can be passed to IC6A, until the MCU reads its PC0 input and gives a command on PD4 to clear the IC6A latch. Working version of the MCU software is also attached, FAT32 functions are still under development.20 Mbit/sec is rather slow by today's standards, but this project is  primarily about security, not speed - cheap, standard and ubiquitous components, all open-source and easily obtainable - our usual design philosophy. Alice can surely wait 20 minutes to copy several gigabytes - after mailing the OTP copy to Bob, they will be able to securely communicate for many years...

Hello daniu, the memory ( RAM ) has not much space left and is even low for the normal opperation of the current software. Also there is only some kByte Flash left for new functions. So adding new functions to the current firmware is not much of an option as this will result in a heavy demand for optimizations and may even a swap of the MCU for one with  slightly more RAM and Flash.  Regards Elektor Labs

Yes, they work the same. The difference between the two is the frequency range and the dynamic range.

added CO2 sensor and the ENS210 work in (slow) progress :-) see https://github.com/JelmerT/esp32weatherstation also designed a more general PCB for development with more I/O possibilities adapted to our needs but still based on the nice Elektor pcb, see https://github.com/JelmerT/esp32weatherstation/tree/master/Hardware/ESP32Weatherstation see drawing of pcb (without powerplanes for clarity)