Are you the publisher? Claim or contact us about this channel


Embed this content in your HTML

Search

Report adult content:

click to rate:

Account: (login)

More Channels


Channel Catalog


Channel Description:

All Content in element14 Community
    0 0

    How to easily decode the WEB SDR transmission. Help needed!

     

    Having returned back to my home city Athens, and fighting my jet lag, I set upon testing all the components for the challenge, just to make sure that they have survived the long trip.

    Unfortunately for some reason that I have not discovered yet, my Edison module that I had so carefully hand carried and undergone flight inspections, would not boot or SSH no matter what I tried.  I used the USB cable through the Arduino IDE but again nothing. Edison’s disk space would not show on my computer. I then tried the “console” mode, but again nothing.

    The blue LED on the Sparkfun base block would light up upon powering the module with 5 volts, but that was it. I increased the input  voltage to the module up to 8,5 volts, but still nothing.

    Fearing the worse, I decided not to waste any further time, so I disassembled the module and decided to try using the second Edison board that I had plugged on the Edison Arduino board with different settings.

    How thoughtful of the sponsors and organizers to provide us with a second Edison core board!

    It helped fighting Mr. Murphy. Upon swapping the Edisons, I got terminal access to it, changed my wifi settings and was able to SSH, using my previous settings.

    Well, that was something. I installed the OLED library and fired my test javascript to make sure that  the display had not gone. I was lucky that everything worked as it should, but now I had to install quite a number of node.js utilities that I was using for my project, as well as my development directory. I had   two backups with me and one on the Cloud!

    This morning I was eventually back to where I was when I left Seattle, but some of my safety backup time had been gone.

    I rescheduled my next steps and decided to increase my working hours, hoping that Murphy’s ghost would go away.

     

    I then decided that if I could install and use a terminal text-only web browser under Yocto, it could help me shorten my development time.

    I borrowed a Linux laptop with a stable Ubuntu version to make testing things easier, as Win10 home was not to my expectations.

    I installed Lynx browser (http://lynx.browser.org/lynx2.8.8/index.html) in order to continue and got text web browsing quite easily.

    But when I tried my test browsing “command”: http://websdr.ewi.utwente.nl:8901/?tune=198am that would put me directly to BBC4 listening, I got the message that my browser did not support HTML5 WebAudio. So practically speaking, although I could get the text image of the site, there was no sound streaming in.

    Then I installed the Chromium-browser for linux on the laptop and I am now trying to make it run without any X window.

    As it fully supports HTML5 WebAudio, I think it would help.

    I tried it on the laptop from command line and it brought the expected result. But I need to make it work without displaying any graphics and then port it to Edison.

     

    Any ideas or recommendation from people with experience on customizing Chromium would be appreciated at this point.

    Meanwhile, I SSH opkg update and now I am doing an opkg upgrade, just to make sure that my new installation will be fine.

    That is all for the time being, while I am trying to solve the Browser issue.

     

    Published Posts
    [Upcycle it Design Challenge] Embedded Web SDR client on Analog Radio Receiver #1: Introduction
    [Upcycle it Design Challenge] Embedded Web SDR client on Analog Radio Receiver #2: Software Concept
    [Upcycle it Design Challenge] Embedded Web SDR client on Analog Radio Receiver #3: Meeting with Edison
    [Upcycle it Design Challenge] Embedded Web SDR client on Analog Radio Receiver #4: Software Challenges with Edison
    [Upcycle it Design Challenge] Embedded Web SDR client on Analog Radio Receiver #5: The Software Challenge goes on
    [Upcycle it Design Challenge] Embedded Web SDR client on Analog Radio Receiver #6: Changing the Display
    [Upcycle it Design Challenge] Embedded Web SDR client on Analog Radio Receiver #7: Hardware is ready!
    [Upcycle it Design Challenge] Embedded Web SDR client on Analog Radio Receiver #8: Problem with Audio.
    [Upcycle it Design Challenge] Embedded Web SDR client on Analog Radio Receiver #9: Problem with Browser

    0 0

    The Raspberry Pi was inspired by the previous generations of computers that booted into a programming environment such as Amigas, BBC Micros, Spectrum ZX and Commodore 64 machines.

     

    When it exceeded 200 times the expected demand they partnered with Premier Farnell to manufacture boards.

     

    The element14 community, set up as the first online community for engineers in 2009 by Premier Farnell had been running since 2009, would never be the same.

     

    Raspberry Pi Gaining STEAM Interest

     

    At the Bay Area Maker Faire 2017, I talked to many educators who were interested in how they could use the Raspberry Pi as part of their STEAM (Science, Technology, Engineering, Arts, and Mathematics) curriculum.  Some people I talked to had heard of the Raspberry Pi but could not tell what was so special about it or what all the fuss was about. To understand what makes the Raspberry Pi so amazing, it's best to put some context to it by comparing it to what came before it. Luckily, there was a computer history booth near by to help me ponder this very issue.

     

    Many people I talked to were educators, some were standing right beside kids as they spoke to me, and were either looking to either get children interested in programming, or understand what attracted the attention of some of the kids they taught. They had no idea about the community's relationship with Raspberry Pi, or that we were the online community of a company that not only distributed, but was one of the manufacturers that the founders of Raspberry Pis turned to when demand was 200 times more than what they could produce.

     

    Old computers are a great place to learn about computers because unlike modern machines you can actually see what's under the hood. They also require you to learn something if you want to get it to do something useful. Computers are more like appliances nowadays and they don't invite same a level of curiosity as the older machines did.  With the rise of tablets and mobile devices, that's even more so the case, and there's industry worry that there won't be enough people with experience to program in the future because we've become custom to working with devices that discourage everyday users from doing anything that would allow them to know what's going on at a root level.

     

    What Makes a Computer?

     

    A single-board computer (SBC) such as the Raspberry Pi is different from a traditional desktop computer with a motherboard. The Raspberry Pi is not the first single-board computer as these have been around about as long as personal computers.  Their usage was mainly confined to demonstration or development systems, for educational systems, or for use as embedded computer controllers.

     

    Here are specs that will be used to compare the different types of computers:

     

    • CPU/Processor - Whenever you issue a command from an input device such as a gamepad, a mouse, or a keypad you're sending instructions to the CPU whose job is to process those commands.  It's considered the brains because it does the figuring whenever you want the computer to do something. A processor's speed is measured in megahertz (MHz) for millions of instructions per second and giga hertz (GHz) for billions of instructions per second.  Keep in mind that the actual speed of the computer varies depending on the individual components used and not just the processor!
    • RAM - Refers to your computer's short term memory.  When the computer is turned off it disappears. It performs calculations for your computer and disappears when it's turned off. RAM is measured in megabytes (MB) or gigabytes (GB).  It allows your computer to do multitask and run separate processes at the same time. The more RAM you have the less likely your computer is going to be sluggish when you are multi-tasking.
      • DRAM (Dynamic Random Access Memory)
      • SRAM (Static Random Access Memory)
    • ROM - This refers to read-only memory that does not disappear when your computer is turned off. It contains instructions that allow your computer to boot up.
      • PROM (Programmable Erasable Memory)
      • EPROM (Erasable Programmable Read-Only Memory)

     

    *DRAM, SRAM are different types of RAM.  PROM and EPROM are different types of ROM.  They are only mentioned here so you don't get confused if you hear the terms.

     

    Retro Computer Gallary

     

    I don't know that I got to see everything that was on display as some people were busy on some of the machines when I arrived but I did see most of them.   Here is what I learned from the experience.

     

    *Earlier this year the Raspberry Pi past the Commodore 64 as the third most popular computer of all-time.

     

    {tabbedtable} Tab Label Tab Content
    Altair 8800

    (1974)

    IMG_1158.jpg

     

    The Altair 8800 system consists of a metal case, a power supply, a front panel with switches, and a passive motherboard with expansion slots.

     

     

    All of the circuitry - the CPU and memory, are on cards which plug into the expansion slots which was called Altair Bus and later renamed S-100 Bus as it became the industry standard.

     

     

    Keyboards and monitors were not cheaply available so users were initially required to flip switches on the front panel, write programs in machine language, and LEDs on the front panel light up in response to commands.

     

     

    Bill Gates and Paul Allen wrote an interpreter for the Machine language, aka a "true" programming language, called Altair Basic. They soon formed their own company called Micro-soft and sold Altair BASIC as their first product.

     

     

    IMG_1160.jpg

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    CPU: Intel 8080

     

    Introductory Kit Price: $439 (roughly around $1,953.92 adjusted for inflation)

     

    Introductory Assembled Price: $621 (roughly around $2763.93 adjusted for inflation)

    KIM-1

    (1976)

     

    A small 6502-based single-board computer developed and produced by MOS Technology, Inc.

     

    While only originally intended for engineers, it found a large audience among hobbyists.

     

    IMG_1146.jpg

    IMG_1147.jpg

    IMG_1148.jpg

    IMG_1149.jpg

     

    CPU: MOS 6502, 1MHz

     

    Memory: 1024 bytes RAM, 2048 bytes ROM

     

    Introductory Price: $245 (roughly around $1,077.49 adjusted for inflation)

    Apple-1

    (1976-1977)

    IMG_1142.jpg

    IMG_1143.jpg

    IMG_1144.jpg

    IMG_1145.jpg

     

     

    CPU: MOS 6502, 1.0 MHz

     

    Memory: 4K, 65K max RAM, 256 bytes ROM

     

    Introductory Price: $666.66 (roughly around $2806 adjusted for inflation)

     

     

    {tabbedtable} Tab Label Tab Content
    Apple II

    (1977-1993)

    IMG_1150.jpg

    IMG_1151.jpg

    IMG_1152.jpg

    IMG_1154.jpg

    IMG_1153 (1).jpg

    IMG_1156.jpg

     

    CPU: MOS 6502, 1.0 MHz

     

    Memory: 4K min, 48K max RAM, 12 K RAM

     

    Introductory Price: $1,298 (roughly around $5,130 adjusted for inflation)

    TRS-80

    (1977-1981)

    IMG_1167.jpg

     

    CPU: Zilog Z80 @ 1.774 MHz

     

    Memory: 4 KB, 48 KB max

     

    Introductory Price: $600 (roughly around $2400 adjusted for inflation)

    Atari 2600

    (1977-1983)


    IMG_1169.jpg

     

    IMG_1170.jpg

     

    CPU: 8-bit MOS 6507@ 1.19 MHz

     

    Memory: 128 bytes RAM, 4 kB ROM

     

     

    Introductory Price: $199 (roughly around $786.49 adjusted for inflation)

     

     

     

     

    {tabbedtable} Tab Label Tab Content
    Commodore PET

    (1977-1982)


    IMG_1161.jpg

     

    IMG_1163.jpg

     

    CPU: MOS Technology 6502 @ 1 MHz

     

    Memory: 4 K or 8 K RAM, 14 K ROM

     

    Introductory Price: $795 (roughly around $3,176 adjusted for inflation)

    Texas Instruments TI-99A/4A

    (1977-1982)


    IMG_1172.jpg

     

    CPU: TI TMS9900 @ 3 MHz

     

    Memory: 256 bytes "scratchpad" RAM + 16 KB VDP (graphics RAM)

     

    Introductory Price: $525 (roughly around $1,383 adjusted for inflation)

    Tandy CoCo3

    (1986-1991)


    IMG_1171.jpg

     

    CPU: Motorola 6809E @ .895 MHz

     

    Memory: 128 kB of RAM, upgradable to 512 kB

     

    Introductory Price: $399 (roughly around $1,160 adjusted for inflation)

     

    Raspberry Pi Changes Everything

     

     

    In 2006, Eben Upton and colleagues including Rob Mullins, Jack Lang, and Alan Mycroft came up with the idea of using a cheap, tiny computer to help teach kids how to code. They were concerned with the year-on-year declining popularity and skill set of A Level students applying for Computer Science in each academic year throughout the 2000's.  Something was clearly going on, the situation had changed drastically from what was happening in the early 1990s, when most kids who applied came to interviews as experienced hobbyist programmers as opposed to someone who did just a little bit of web design.

     

    A number of problems for why kids interacted differently with computers were identified: combining ICT curriculum with lessons on using Word and Excel, or writing web pages; the dot-com bust; and the rise of home PC and game consoles to replace the Amigas, BBC Micros, Spectrum ZX and Commodore 64 machines that the previous generation had grown up and learned to program on. While the consolidation of curriculum and the end of the .dom era are issues a small group of people could not address, reinvigorating an interest in programming lost on those growing up with modern computers was something they felt they could help with. Unlike modern computers, which were cost prohibitive and did not lend themselves to programming experimentation, the older computers of the previous generation could be booted into a programming environment.

     

     

     

    Raspberry Pi Zero Portable Episode

     

    Several iterations of what would later be known as the Raspberry Pi were designed from Eben from 2006 to 2008. The idea gain steam until 2008, when processors used in mobile devices became more affordable and powerful enough to deliver a quality multimedia experience, making the boards attractive for kids not interested in a purely programming-oriented device. Eben Upton, Rob Mullins, Jack Lang, and Alan Mycroft teamed up Pete Lomas and David Braben to form the Raspberry Pi foundation and turn their vision into a reality.

     

    The foundation also had several challenges including no manufacturing experience, price points with margins under acceptable levels for contract manufacturers, and volumes that were too low.  The original plan for the Raspberry Pi called for building just 1000 units for new undergraduates at Cambridge University. They figured they could operate at an initial loss by kick starting the project themselves and further develop the platform while early adopters helped with debugging, documentation, and education.

    Raspberry-Pi-3-top-down-web.jpg

     

    CPU: 64-bit quad-core ARM Cortex-A53 @ 1.2 GHz

     

    Memory: 1 GB RAM at 900 MHz

     

    Introductory Price: $35

     

    Instead, they became victims to their own success when just three weeks before launch, initial demand went well beyond 200,000 units.  It would be impossible for them to subsidize production at a level 200 times beyond what they initially expected and they could not fund demand by normal loan methods because they were registered as a UK charity. As as result, they began searching for a partner with the buying power to keep component prices low, the global presence to handle logistics, and the financial muscle to make it all happen immediately.

     

    According to Pete Lomas: "What we learned is that we had to sell out (a little) to sell (a lot). I'd argue that many makers do this when they want to scale... Holding back schematics altogether troubled us. Not being open would impede people's ability to interface and hack the hardware - defeating the very goals we had set out to accomplish with Raspberry Pi in the first place. Because our remit is education in the broadest sense, we wanted - needed - to provide completely open access to the hardware. And we didn't want to alienate the devoted hacking and open source community that had fueled early interest and would provide much future development. ...But if other manufacturers copied our design, our partners would lose their investment, which was approaching several million dollars. They were spending this time and money optimizing their processes for manufacturing our product, while exploring component alternatives to meet our cost target."

     

    The final design for the Raspberry Pi included what is perhaps its most important feature for the hacker and open source community, access to the General Purpose Input/Output (GPIO). Pete Lomas continues: "The GPIO was the key to unlocking the hardware so successfully developed in the Arduino ecosystem: The stuff people could add to and embed with the Raspberry Pi. The GPIO also meant features that ended up on the cutting room floor could be added back by our ever-inventive community. ...without all these specs, a hardware community could not grow around the Raspberry Pi."

     

    The Raspberry Pi was released by Premier Farnell, the company behind element14, in 2012. According to the CEO at the time: "This partnership brings together the world's biggest online design engineer community with one of the most exciting electronic/embedded computing products to be launched for decades. ...Through our element14 community we will encourage everyone from developers, modders, coders and programmers to discuss, share and develop their ideas and fully (utilize) the game-changing potential of the Raspberry Pi computer."


    0 0

    (sorry for my bad English)

     

    hello,

    I've got two codes, one is a simple blink with delay , and another is Leap Motion

    I want to combine these two codes and I hope it could work like this :

    The blink code runs, and as Leap Motion detect hand, it turns to run my Leap Motion code,

    BUT my blink code continues, my blink code looped every 3 minutes, and I had sound for it

    so I don't want when it turns to Leap Motion code it paused cause it will not match my sound after,

     

    please help, thanks !

     

    int val;
    long randomNumber;


    int ledPin = 1;
    int ledPin2 = 2;
    int ledPin3 = 3;
    int ledPin4 = 4;
    int ledPin5 = 5;
    int ledPin6 = 6;
    int ledPin7 = 7;
    int ledPin8 = 8;
    int ledPin9 = 9;
    int ledPin10 = 10;
    int ledPin11 = 11;
    int ledPin12 = 12;
    int ledPin13 = 13;
    int ledPin14 = 14;

    int laser = 15;
    int laser2 = 16;
    int laser3 = 17;
    int laser4 = 18;
    int laser5 = 19;
    int laser6 = 20;
    int laser7 = 21;
    int laser8 = 22;



    void setup() {

      pinMode(ledPin, OUTPUT);
      pinMode(ledPin2, OUTPUT);
      pinMode(ledPin3, OUTPUT);
      pinMode(ledPin4, OUTPUT);
      pinMode(ledPin5, OUTPUT);
      pinMode(ledPin6, OUTPUT);
      pinMode(ledPin7, OUTPUT);
      pinMode(ledPin8, OUTPUT);
      pinMode(ledPin9, OUTPUT);
      pinMode(ledPin10, OUTPUT);
      pinMode(ledPin11, OUTPUT);
      pinMode(ledPin12, OUTPUT);
      pinMode(ledPin13, OUTPUT);
      pinMode(ledPin14, OUTPUT);

      pinMode(laser, OUTPUT);
      pinMode(laser2, OUTPUT);
      pinMode(laser3, OUTPUT);
      pinMode(laser4, OUTPUT);
      pinMode(laser5, OUTPUT);
      pinMode(laser6, OUTPUT);
      pinMode(laser7, OUTPUT);
      pinMode(laser8, OUTPUT);

      Serial.begin(9600); // Start serial communication at 9600 bps

    }

    void loop() {


      //LEAP PART
      randomNumber = random(2, 16);

      if (Serial.available())
      {
        val = Serial.read();
      }
     
      if (val != 0){
       
     
      if (val == 1)
      {
        digitalWrite(ledPin, HIGH);
        digitalWrite(ledPin2, HIGH);
        digitalWrite(ledPin3, HIGH);
        digitalWrite(ledPin4, HIGH);
        digitalWrite(ledPin5, HIGH);
        digitalWrite(ledPin6, HIGH);
        digitalWrite(ledPin7, HIGH);
        digitalWrite(ledPin8, HIGH);
        digitalWrite(ledPin9, HIGH);
        digitalWrite(ledPin10, HIGH);
        digitalWrite(ledPin11, HIGH);
        digitalWrite(ledPin12, HIGH);
        digitalWrite(ledPin13, HIGH);
        digitalWrite(ledPin14, HIGH);
        delay(1000);
        digitalWrite(ledPin, LOW);
        digitalWrite(ledPin2, LOW);
        digitalWrite(ledPin3, LOW);
        digitalWrite(ledPin4, LOW);
        digitalWrite(ledPin5, LOW);
        digitalWrite(ledPin6, LOW);
        digitalWrite(ledPin7, LOW);
        digitalWrite(ledPin8, LOW);
        digitalWrite(ledPin9, LOW);
        digitalWrite(ledPin10, LOW);
        digitalWrite(ledPin11, LOW);
        digitalWrite(ledPin12, LOW);
        digitalWrite(ledPin13, LOW);
        digitalWrite(ledPin14, LOW);
        delay(1000);


      } else if (val == 2)
      {
        digitalWrite(ledPin, HIGH);
        digitalWrite(ledPin2, HIGH);
        digitalWrite(ledPin3, HIGH);
        digitalWrite(ledPin4, HIGH);
        digitalWrite(ledPin5, HIGH);
        digitalWrite(ledPin6, HIGH);
        digitalWrite(ledPin7, HIGH);
        digitalWrite(ledPin8, HIGH);
        digitalWrite(ledPin9, HIGH);
        digitalWrite(ledPin10, HIGH);
        digitalWrite(ledPin11, HIGH);
        digitalWrite(ledPin12, HIGH);
        digitalWrite(ledPin13, HIGH);
        digitalWrite(ledPin14, HIGH);
        delay(700);
        digitalWrite(ledPin, LOW);
        digitalWrite(ledPin2, LOW);
        digitalWrite(ledPin3, LOW);
        digitalWrite(ledPin4, LOW);
        digitalWrite(ledPin5, LOW);
        digitalWrite(ledPin6, LOW);
        digitalWrite(ledPin7, LOW);
        digitalWrite(ledPin8, LOW);
        digitalWrite(ledPin9, LOW);
        digitalWrite(ledPin10, LOW);
        digitalWrite(ledPin11, LOW);
        digitalWrite(ledPin12, LOW);
        digitalWrite(ledPin13, LOW);
        digitalWrite(ledPin14, LOW);
        delay(700);
      } else if (val == 3)
      {
        digitalWrite(ledPin, HIGH);
        digitalWrite(ledPin2, HIGH);
        digitalWrite(ledPin3, HIGH);
        digitalWrite(ledPin4, HIGH);
        digitalWrite(ledPin5, HIGH);
        digitalWrite(ledPin6, HIGH);
        digitalWrite(ledPin7, HIGH);
        digitalWrite(ledPin8, HIGH);
        digitalWrite(ledPin9, HIGH);
        digitalWrite(ledPin10, HIGH);
        digitalWrite(ledPin11, HIGH);
        digitalWrite(ledPin12, HIGH);
        digitalWrite(ledPin13, HIGH);
        digitalWrite(ledPin14, HIGH);
        delay(300);
        digitalWrite(ledPin, LOW);
        digitalWrite(ledPin2, LOW);
        digitalWrite(ledPin3, LOW);
        digitalWrite(ledPin4, LOW);
        digitalWrite(ledPin5, LOW);
        digitalWrite(ledPin6, LOW);
        digitalWrite(ledPin7, LOW);
        digitalWrite(ledPin8, LOW);
        digitalWrite(ledPin9, LOW);
        digitalWrite(ledPin10, LOW);
        digitalWrite(ledPin11, LOW);
        digitalWrite(ledPin12, LOW);
        digitalWrite(ledPin13, LOW);
        digitalWrite(ledPin14, LOW);
        delay(300);
      } else if (val == 4)
      {
        digitalWrite(ledPin, HIGH);
        digitalWrite(ledPin2, HIGH);
        digitalWrite(ledPin3, HIGH);
        digitalWrite(ledPin4, HIGH);
        digitalWrite(ledPin5, HIGH);
        digitalWrite(ledPin6, HIGH);
        digitalWrite(ledPin7, HIGH);
        digitalWrite(ledPin8, HIGH);
        digitalWrite(ledPin9, HIGH);
        digitalWrite(ledPin10, HIGH);
        digitalWrite(ledPin11, HIGH);
        digitalWrite(ledPin12, HIGH);
        digitalWrite(ledPin13, HIGH);
        digitalWrite(ledPin14, HIGH);
        delay(100);
        digitalWrite(ledPin, LOW);
        digitalWrite(ledPin2, LOW);
        digitalWrite(ledPin3, LOW);
        digitalWrite(ledPin4, LOW);
        digitalWrite(ledPin5, LOW);
        digitalWrite(ledPin6, LOW);
        digitalWrite(ledPin7, LOW);
        digitalWrite(ledPin8, LOW);
        digitalWrite(ledPin9, LOW);
        digitalWrite(ledPin10, LOW);
        digitalWrite(ledPin11, LOW);
        digitalWrite(ledPin12, LOW);
        digitalWrite(ledPin13, LOW);
        digitalWrite(ledPin14, LOW);
        delay(100);
      }





      else if (val == 5)
      { digitalWrite(randomNumber, HIGH);
        delay(1000);
        digitalWrite(randomNumber, LOW);
        delay(1000);
      } else if (val == 6)
      { digitalWrite(randomNumber, HIGH);
        delay(500);
        digitalWrite(randomNumber, LOW);
        delay(500);
      } else if (val == 7)
      { digitalWrite(randomNumber, HIGH);
        delay(300);
        digitalWrite(randomNumber, LOW);
        delay(300);
      } else if (val == 8)
      { digitalWrite(randomNumber, HIGH);
        delay(100);
        digitalWrite(randomNumber, LOW);
        delay(100);

      } else if (val == 9)
      {
        digitalWrite(ledPin8, LOW);
        digitalWrite(ledPin9, LOW);
        digitalWrite(ledPin10, LOW);
        digitalWrite(ledPin11, LOW);
        digitalWrite(ledPin12, LOW);
        digitalWrite(ledPin13, LOW);
        digitalWrite(ledPin14, LOW);
        delay(10);

      } else if (val == 10)
      {
        digitalWrite(ledPin, LOW);
        digitalWrite(ledPin2, LOW);
        digitalWrite(ledPin3, LOW);
        digitalWrite(ledPin4, LOW);
        digitalWrite(ledPin5, LOW);
        digitalWrite(ledPin6, LOW);
        digitalWrite(ledPin7, LOW);
        delay(10);

      }
      }

     
      if (val == 0){
      // laser part 01



      delay(15000);
      digitalWrite(laser, HIGH);
      delay(1500);
      digitalWrite(laser, LOW);
      delay(6500);
      digitalWrite(laser3, HIGH);
      delay(1500);
      digitalWrite(laser3, LOW);
      delay(6500);
      digitalWrite(laser5, HIGH);
      delay(1500);
      digitalWrite(laser5, LOW);
      delay(6500);
      digitalWrite(laser7, HIGH);
      delay(1500);
      digitalWrite(laser7, LOW);
      delay(3000);
      digitalWrite(laser2, HIGH);
      delay(700);
      digitalWrite(laser2, LOW);
      delay(3000);
      digitalWrite(laser4, HIGH);
      delay(700);
      digitalWrite(laser4, LOW);
      delay(3000);
      digitalWrite(laser6, HIGH);
      delay(700);
      digitalWrite(laser6, LOW);
      delay(3000);
      digitalWrite(laser8, HIGH);
      delay(700);
      digitalWrite(laser8, LOW);



      delay(34000);
      digitalWrite(ledPin, HIGH);
      digitalWrite(ledPin2, HIGH);
      digitalWrite(ledPin3, HIGH);
      digitalWrite(ledPin4, HIGH);
      digitalWrite(ledPin5, HIGH);
      digitalWrite(ledPin6, HIGH);
      digitalWrite(ledPin7, HIGH);
      delay(500);
      digitalWrite(ledPin, LOW);
      digitalWrite(ledPin2, LOW);
      digitalWrite(ledPin3, LOW);
      digitalWrite(ledPin4, LOW);
      digitalWrite(ledPin5, LOW);
      digitalWrite(ledPin6, LOW);
      digitalWrite(ledPin7, LOW);
      delay(500);

      digitalWrite(laser, HIGH);
      delay(500);
      digitalWrite(laser, LOW);

    }


    0 0

    infeon logo.gif

     

    {tabbedtable} Tab Label Tab Content
    About

    The Infineon DC motor shield is a small evaluation board equipped with  TLE94112EL for use with Arduino. The TLE94112EL is capable to drive up to 6 small DC motors in parallel mode or up to 11 DC motors in cascaded mode. All outputs can drive up to 0.9A. The outputs can be used stand-alone or combined to increase driving capability up to 3.6A.

     

    DC_Motor_Shield_TLE94112EL_and_DEBUG_Peresp_plain.jpg

    Infineon DC Motor Shield with XMC1100 Boot Kit for Arduino

     

     

    Features:

    Driver with 12 half-bridge outputs to drive DC motors, resistive or inductive loads

    • Driver is protected against over-temperature, over-current, over-voltage, under-voltage and enables diagnosis of over-current, over-voltage, under-voltage
    • SPI interface with zero clock diagnosis
    • Enhanced EMC performance
    • Integrated PWM generator with 3 different frequencies (80Hz, 100Hz, 200Hz)

     

    Benefits:

    • Shield enables compact design for multi-motor applications
    • Cost efficient design for multi-motor applications
    • Less communication with µC through integrated PWM generator and zero clock diagnosis
    • Lower cost by reducing external components to EME requirements

     

    Applications:

    • Multi-motor applications
    • DC motors and voltage controlled bipolar stepper motors
    • Toys
    • HVAC systems

     

    Click here to obtain XMC1100 Software for Arduino IDE

    Important Dates

    Enrollment Begins: Mar 12 2017

    Enrollment Ends: Apr 18, 2017

    RoadTesters Selected: Apr 25 2017 (estimated)

    Product Shipped: TBD

    RoadTesting Begins: TBD

    Reminder/Update Email: TBD*

    Submit Reviews By: TBD**

     

    *The element14 RoadTest Staff will send this reminder/update email.

    **If a RoadTester is unable to meet the deadline, please notify the RoadTest Program Lead, rscasny, as soon as possible before the deadline.

    RoadTesters

    The supplier selected the following applicants as official RoadTesters:

     

    balearicdynamics

    geralds

    momososo

    sandeepmaraprem@gmail.com

    bdrake@avantia-inc.com

    atiflz

    deploylab

    shwetankv007

    tgbuzz

    gam3t3ch

    Terms & Conditions

    DC Motor Shield with TLE94112EL for Arduino – RoadTest

    Terms and Conditions

    These are the terms and conditions which govern the DC Motor Shield with TLE94112EL for Arduino RoadTest contest. This Contest requires participants to submit an application indicating their previous experience with this type of equipment/component, information on what they would do to test the equipment/component, and the applicant’s desire to post a thorough review of their experience with images, photos, or other supplemental materials. Participants will be required to meet the Conditions for Participation.  The winners of this RoadTest will receive the item(s) listed below. RoadTest Reviews are due no later than 60 days after the receipt of the item(s). No other prizes are offered.

    The Principal terms of the Competition:

    The following words and phrases are used in these terms and conditions and have the meanings given to them below.

    RoadTest: DC Motor Shield with TLE94112EL for Arduino

    (RoadTest or Contest)

    Key dates:

    Applications Close: midnight (GMT) on 17 March 2017

    Announcement of Winner (estimated): 24 Mar 2017

     

    Prize:  DC Motor Shield with TLE94112EL for Arduino

    Additional Prizes: none

    Competition Site: https://www.element14.com/community/groups/roadtest?ICID=menubar_resources_roadtest

    Site or element14 Community: www.element14.com/community

    Judges: members of the element14 community team chosen at the Organiser’s discretion.

    Judging Criteria, All of the following which will have equal weighting:

    · Demonstrated competence with the technologies including links or descriptions of past projects

    · Qualifications as indicated by current job role and/or schooling/vocational training;

    · A thorough description of how the prize would be tested;

    · Likelihood that the Applicant will blog about the prize and provide a review on element14.com;

    · Originality;

    · Innovation.

    Organiser: Premier Farnell plc (registered in England and Wales under company number 876412) whose registered office is at Farnell House, Forge Lane, Leeds, UK

    Conditions for Qualification: in addition to meeting the requirements of these terms, all persons applying to take part in the Contest (each one an Applicant) must:

    · Provide a RoadTest application describing what he/she would do if awarded the Prize including similar previous projects, product experience and qualifications

    Terms: these terms and conditions which govern the Competition and to which the Organiser reserves the right to make changes from time to time and the latest version of these Terms from time to time will be posted to the Site.

    1. Eligibility
    2. Applications:
    3. Selecting Winners:   
    4. Liability:
    5. General:

    1.1 Save as set out in these Terms, the Contest is open to any natural or legal person, firm or company or group of natural persons or unincorporated body.

    1.2 All Applicants must be aged at least 18 at the time of their application.

    1.3 Applicants must not enter the RoadTest if doing so or taking part may:

    1.3.1 cause the Organiser and/or themselves to be in breach of any agreement (including but not limited to any contract of employment) to which they are a party or in breach of any law, regulation or rule having the force of law to which the Organiser or the Applicant may be subject or any policy of the Organiser or the Sponsor;

    1.3.2 Require the Organiser to obtain any licence, authorisation or permission to deal with the Applicant; or

    1.3.3 Be in breach of any policy or practice of their employer. Some employers prohibit or restrict their employees from taking part in competitions such as these or receiving prizes under them and the Organiser respects those policies and practices.

    The Organiser reserves the right to disqualify any Application made in breach of these Terms and to reject any Application which it reasonably believes may be or become in breach. The Organiser reserves the right to require evidence in such form as the Organiser may reasonably require of any Applicant’s compliance with any of these Terms and to disqualify any Applicant or Participant who cannot provide such evidence reasonably promptly. 

    1.4 Multiple applications are not permitted.

    1.5 Applications may not be submitted by an agent whether acting on behalf of an undisclosed principal or otherwise.

    1.6 The Contest is NOT open to:

    1.6.1 Any person or entity who is a resident or national of any country which is subject to sanctions, embargoes or national trade restrictions of the United States of America, the European Union or the United Kingdom;

    1.6.2 Any employee, director, member, shareholder (as appropriate) or any of their direct families (parents, siblings, spouse, partner, children) (“Direct Families”) of the Organiser and Sponsors; or

    2.1 Each Applicant must fully complete and submit a RoadTest Application by the Application Close.

    2.2 By submitting a Registration Form, each Applicant:

    2.2.1 Authorises the Organiser to use his or her personal data (as defined in the Data Protection Act 1998) for the purposes of running and promoting the RoadTest;

    2.2.2 Authorises the Organizer to copy, reproduce and publish their application should they be accepted as a Participant;

    2.2.3 Will be deemed to have read, accepted and agree to be bound by these Terms. Applicants are advised to print and keep safe these Terms;

    2.2.4 Authorises the Organiser to copy, reproduce and use the Application and/or Review for the purposes of the RoadTest and as otherwise contemplated by these Terms. The Organiser will not be responsible for any inaccuracy, error or omission contained in any reproduction or use of the Project Blogs.

    2.2.5 Licenses the Organiser to use the intellectual property in the Project (IP) for the purposes of this Contest. As between the Applicant and the Organiser the IP remains owned by the Applicant.

    2.2.6 Grants the Organiser the right to use his or her likeness, photographs, logos, trademarks, audio or video recordings without restriction for the purposes of Contest or the promotion of it or the Site;

    2.2.7 Agrees to participate positively in all publicity surrounding the Contest;

    2.2.8 Agrees to be responsible for all expenses and costs incurred by him or her in preparing for, entering and participating in the Contest (save for any expenses expressly agreed by the Organiser to be borne by it in these Terms);

    2.2.9 Confirms that he or she owns all IP used in his or her application or Project or Blogs and indemnifies the Organiser from any claim by a third party that use of any material provided by an Applicant to the Organiser infringes the intellectual property rights of any third party;

    2.2.10 Agrees not to act in any way or fail to act in any way or be associated with any cause or group which would have a negative impact on the reputation of the Organiser and/or the RoadTest.

    2.3 All applications submitted to this RoadTest must meet the following criteria:

    2.3.1 Applicants must be the author, creator and owner of the proposed review idea. Applicants must not submit someone else’s idea;

    2.3.2 The proposed application must be reasonably achievable by the within the time constraints of the Contest; 

    2.3.3 Applications must not include or propose any of the following, the inclusion of which shall render any proposed application ineligible:

    (a) Applications which relate to socially taboo topics, such as illicit drug use or sexual gratification;

    (b) Applications that are or could reasonably be considered to be illegal, immoral, discriminatory or offensive as determined by the Organiser;

    (c) Applications in relation to them which if accepted would infringe or breach any of the policies or terms of access or use of the Site.

    2.4 No Application may contain any of the hazardous substances identified by Article 4 of Directive 2002/95/EC of the European Parliament on the Restrictions on the Use of Substances in Electronic and Electrical Equipment ("the Directive") or the use of such hazardous substances in the in any such Project must not exceed the maximum concentration values set out in the Directive.

    3.1 Winners will be selected by the Organiser on the basis of the quality of his or her application and its adherence to these Terms.

    3.2 The total number of Winners selected will be at least the minimum number set out above but the actual number is at the sole discretion of the Organizer and/or the Sponsor, if applicable.

    3.3 The Organiser will use all reasonable efforts to announce the Winners via an update to the RoadTest page by the date listed above.

    3.4 Winners agree to take part in all publicity which the Organiser or the Sponsor wishes to use to promote the RoadTest, the Products featured or other Contests with which the Organiser may be connected from time to time.

    3.5 Details of the Winners may also be published in the media.

    3.6 Winners are responsible for all applicable taxes, duties or other charges payable in relation to any prize.

    3.7 

    4.1 The Organiser hereby excludes all and any Liability arising out of the Contest or the acceptance, use, quality, condition, suitability or performance of any Prize, even where that Liability may arise from the Organiser’s negligence.

    4.2 Nothing in these Terms will affect any Liability of the Organiser for death or personal injury arising from its negligence, for breach of Part II of the Consumer Protection Act 1987 (in the event that any entrant is entitled to claim rights under the Consumer Protection Act 1987) or for any matter in relation to which it would be illegal for the Organiser to exclude or to attempt to exclude its Liability.

    4.3 Subject to 4.2, neither the Organiser, any parent company nor any subsidiary of the Organiser or such parent company or any of their directors, officers and employees (together referred to in these terms and the ‘Associates’) makes any guarantee, warranty or representation of any kind, express or implied, with respect to this Competition or the Prizes potentially available under it. Neither the Organiser nor any of its Associates shall be responsible for any Liability that may arise out of or in connection with person’s participation in this Competition, the claiming, redemption or value of any prizes under it, the use or enjoyment of such prizes or any events or circumstances arising out of or in connection with any of them. Any implied warranties of condition, merchantability or suitability or fitness for purpose of any of them are hereby expressly excluded. Wherever used in these Terms, ‘Liability’ shall mean any and all costs, expenses, claims, damages, actions, proceedings, demands, losses and other liabilities (including legal fees and costs on a full indemnity basis) arising directly or indirectly out of or in connection with the matter concerned. 

    5.1 The RoadTest is organised and sponsored by the Organiser. The Organiser reserves the right to delegate all or any of its powers, rights and obligations arising in relation to the RoadTest to any Associate and certain such rights and powers are assumed by the Organiser on behalf of itself and each Associate. Reference to “Organiser” shall be deemed to include reference to each Associate.

    5.2 The RoadTest may be terminated at any time if there are, in the sole opinion of the Organiser, an insufficient number of entries, or if the Applications are not of an appropriate standard for a competition of this nature. The Organiser has the right to cancel or suspend the RoadTest at any time due to circumstances outside its reasonable control.

    5.3 The Organiser shall have the sole discretion to disqualify (without correspondence or right of appeal) any Applicant it considers to be adversely affecting the process or the operation of the RoadTest or to be in breach of these Terms or to be acting in a disruptive manner or with intent to annoy, abuse, threaten or harass any other Applicant or Participant.

    5.4 The Organiser has the right to amend or add to these Terms from time to time. Revised Terms and Conditions will be posted on the Contest Site and it is a condition of entry to the RoadTest that Applicants agree to comply with these Terms and, if appropriate, such Terms as amended from time to time.

    5.5 Headings are for convenience only and do not affect the interpretation or construction of these Terms and Conditions.

    5.6 These Terms and the operation of the Contest shall be governed by and construed in accordance with English Law and any claim or matter arising under these Terms shall be subject to the exclusive jurisdiction of the English courts.


    0 0

    Correction:"Just to clarify how the Dangerous NFC app works - it does not lock the tag, it disables the one-time-programmable lock bytes so it cannot be locked (by accident or maliciously). It also protects the configuration blocks and password block itself. More information on exactly what it does can be found here; https://forum.dangerousthings.com/t/dnfc-and-password-protection" 2 Days after implantation of our Dangerous Things xNT. Our thoughts on the healing process and me thinking I broke it while trying to program it!

    0 0
  • 05/22/17--13:42: A perspective on Testing.
  • Testing is a natural scientific response to confirm or dispel an idea.

    Testing falls into two primary functions, Verification and Validation.

     

    Most people are familiar with Verification testing.  You use the tests to verify that the idea/device/system provides the expected outputs given the proper input stimulus.

     

    In component testing, you want to verify that the device responds as designed or advertised.  I have had a lot of fun with the latter as some marketers just cannot help themselves when making outlandish claims for their new toys.

    I worked as an Independent Verification and Validation engineer on some very large aerospace systems and I had a wonderful time deflating exotic ideas about the technology implementations being developed.

     

    For the most part, Verification Testing is straight forward.  You establish the inputs and measure the outputs.  Standard black box testing technique.  The device either meets specification or it does not.

     

    Validation Testing is similar but very different from Verification Testing.

     

    Validation involves analyzing the resulting Verification Testing results to determine if the final product satisfies the intended uses of the product.

     

    In essence, Validation assess the question of can the intended users, use the product to do the job they need it to do.

     

    Depending upon your user base, this becomes a very difficult task.

    Each user has a perceived notion of what the product needs to do for them.  Very subtle implementation decisions can result in a product that is technically perfect, but useless.  Sort of like contacting Microsoft Support!

     

    In some cases, Validation testing takes you out of the comfortable area of specific input and output and into a more fuzzy world of user perception.  Not an easy task, thought there are some excellent analysis tools available to help resolve this level of testing.

     

    Most of my current work involves Validating my current solution for a Unified Field Theory.

    The issues involved are both technical and perception.  Many of the existing scientific theories are used with both verified test results and with rationalized validation through consensus.

     

    This last issue is the biggest hurdle.  Especially since I bring into question the works of Nobel Laureates in Theoretical Physics for the past 120 years.

    When I tried to verify their results, I discovered that most have never been really validated or indeed verified with hard testing.

     

    That result surprised me.  I had been taught that science was built entirely by independently verified testing.

     

    That is not the case with many of the current Theoretical Physics Theories.  The excuse has been based upon the level of complexity and untestable nature of the issues involved. 

     

    Using standard analysis of public domain data, I have been able to show that most of these excuses are not true and that those theories are false.

     

    So my advice on any of the current theories is to trust but verify.  There is nothing, including ideas, that cannot be tested.

    If someone cannot provide a theoretical model that cannot be tested, then it should not be used until sufficient model definition is developed and adequate independent testing can occur.

     

    DAB


    0 0

    Our ultra high precision current sense resistors are designed to surpass the requirements of the most demanding applications. 40 A pulse test .012 S results in very small drift. http://bit.ly/2qj0S3O

    CSM3637 Pulse test.jpg


    0 0

    DCWklyGnrcHdr.png

     

    Welcome to another installment in the Design Challenge Weekly Summary series here at Element14! It’s week fourteen of the Safe and Sound Wearables Design Challenge and this week also marks the tenth week of the Upcycle it Design Challenge. Project updates were again a little light this week in the Safe and Sound challenge, while the participants in the UpCycle It challenge continued with another solid week of updates across several projects. We have a lot to cover, so let's just jump right into it.

     

    Safe & Sound Design Challenge

     

    Featured as the first design challenge of 2017, the Safe & Sound Wearables challenge tasks its participants to conceive and build a 'safe and sound’ wearable that protects a person from personal and environmental risks, or monitors personal health or protects personal property from theft.

     

     

     

    The Official Kit, and The Prizes

     

    Texas-Instruments-logo-design.png                        DJI_Innovations_logo.svg.png

     

    On February 14th 2017 Element14 announced the list of the official 15 challengers picked to participate in the challenge, and those 15 challengers received a kit of components to use in their design which was sponsored by Texas Instruments. Each kit contains the following items:

     

    Participation in this challenge is not limited to the sponsored challengers however. Anyone can enter, and all they have to do is Design with TI - integrating Texas Instruments’ latest microcontroller (MSP-EXP432P401R)MSP-EXP432P401R LaunchPadMSP-EXP432P401R LaunchPad into a wearable that is Safe & Sound.

     

     

    The Past Week In Review

     

    In the past week, May 14 - May 20, we have had a total of two updates posted across two  individual projects. As with each of my updates, I like to highlight at least three of the past week’s updates, but with just two updates this week I will be highlighting just one of these projects. Before we get to that, let's take a quick look at which projects were updated in the past seven days. 

     

     

    This Week’s Top Update

     

      • T-Shirt for Monitoring Elderly and Physically Challenged Patients #9 : Back on Track, Meet Mr.Edison

     

    WP_20170514_01_19_47_Pro.jpg

     

    After recovering from a PC crash, Sakthivigneshwar R (sakthi.1260) is back on track with his project, T-Shirt for Monitoring Elderly and Physically Challenged Patients after a two week absence. In this weeks update, he works getting the Intel Edison talking to the Texas Instruments Launchpad, so that the Launchpad can relay important sensor data back for processing. To do this Bluetooth was utilized, and after writing a short Arduino sketch, the two boards were successfully talking to each other. Hit the link above for the full rundown, and to view the sketch.

     

    Upcycle It Design Challenge

     

    About The Challenge

     

    Featured as the second design challenge of 2017, the Upcycle It design challenge tasks its participants to upcycle an obsolete item, computer, piece of electronic equipment or appliance and make a cool new electronics project built around the Intel® Edison Kit for Arduino.

     

     

    The Official Kit, and The Prizes

     

    Challengers will build their projects using an official assortment of parts from Arduino, Intel, and Element14. Each kit contains the following items:

     

    The Upcycle it Design Challenge features 15 official challengers that received a Challenger Kit for FREE, but thereafter anyone can join the Challenge simply by posting in the Upcycle it space (tagging their blogs 'upcycle it') to be in with a chance to win prizes. Anyone completing a project by the June 4th deadline and posting at least 10 times on the Community detailing their project build will be in the running to win some awesome prizes, including a Keithley DMM7510 Digital MultimeterKeithley DMM7510 Digital Multimeter worth almost $4,000.

     

    *The official Challengers must build their project in accordance with the challenge's terms and conditions. All projects must include the Intel® Edison.

    The Past Week In Review

     

    In the past week, April 14 - May 20, we have had a total of thirteen updates posted across nine projects. With so many projects this week I will be highlighting three that I found helpful, educational, or just interesting in general. Before we get to this week’s highlighted post,let's take a quick look at which projects were updated in the past seven days. 

     

     

    This Week’s Top Updates

     

      • Washing Machine Hydroponic Grower - #6 Drum Modification

     

    IMG_20170512_182715968.jpg

     

    It’s been a few weeks since we last heard from Fernando Hila (nandohila), but progress is still moving forward on project Washing Machine Hydroponic Grower. In this week’s update he clued readers in on what type of baskets and growing medium he would be using inside the washing machine’s basket. “I got some small growing baskets measuring around Ø 55mm and 35mm high. Those baskets comes with a foam/sponge that is the growing medium for the plant. I found this basket type the most suitable to this application as other types of growing mediums wouldn't stay in place once the drum start turning,” he said. Check out the full post at the link above!

     

     

      • Stay focused in the sky #4: 3D printed gears and the stepper motor is mounted

     

    20170423_140125.jpg

     

    Our second featured post this week focuses on yet another project that has been absent as of late. In update number four of Miguel Angel Garcia Fuentes’ (pcmike2099) project Stay Focused In The Sky took a major leap forward with the design and 3D printing of a set of gears that are to be mounted to the telescope mount. While this update is not very information rich, I decided to feature it to remind the challengers that I really like to see the design files for parts such as this shared with the community at home. This allows those wanting to replicate your project, all the necessary things to do so. It’s still a nice update, but it could be even better if the files were available for download. Check out the link above for more!

     

      • Embedded Web SDR client on Analog Radio Receiver #8: Problem with Audio.

     

    old+usb.jpg

     

    Konstantinos Konstas’ (konstantinoskonstas) project, Embedded Web SDR client on Analog Radio Receiver hit a small snag this past week when the USB Audio dongle he purchased for the project having issued when interfacing with the Intel Edison. “I had tested the card before,in terms of Linux connectivity and I was confident that it was working as I have been using that USB Audio dongle for over a year now in my Amateur Radio activities with a number of programs for decoding/encoding digital data and was quite happy with it,” he said. “It worked under Linux and Win10 as well, so when I probed it from the Edison and saw the dongle's red led blinking, indicating that the card should be working I felt sure that everything was OK. Well not exactly the case. I plugged the headphone output to my amp system but no sound would be produced. I ran my little demo from Yocto bash but again no sound. However, the card was properly selected and the “aplay” command would only blink the dongle's led.” He solved this issue by replacing the audio card with another module. Hit the link above to read the full update!

     

     

    That is going to wrap up things for this week. I want to take a moment to apologize again for this post being late. I caught cold last week that morphed into a full blown illness by the weekend, and I am just now beginning to recover. Hopefully I can return to my normal schedule next week, so remember to check back next week for another Design Challenge Weekly Summary post. Until then head over to the official Safe & Sound Wearables Challenge Page, as well as the Upcycle It Challenge’s landing page fore more Design Challenge content! As always, remember to hack the world and make awesome!


    0 0

    To start programming the stepper motor control, I did some tests having the stepper motor turning the drum at different pulse frequencies.

     

    Checking some other rotary growing systems I found that it normally takes 30 to 45 minutes to give a complete turn. I found it very slow (about 0.025 RPM). The beauty of having a stepper motor is that we can virtually set it at any speed below its maximum RPM.

     

    I decided to physically check the drum RPM applying different pulse frequencies to the stepper controller and measure the turn time. Doing this test I could get the constant relation in between pulse width (ms) and the actual drum RPM.

     

    Below is the code for the testing. I set different pulse frequencies at different pins so I shift the pulse wire through the pins and measured the rotation time.

     

     

     

    //Pulses pins 13, 9 & 8 at different frequencies

     

     

    const int pulsePin13 = 13;             // pin 13 @ 1000ms (on board LED)

    const long interval13 = 1000;          // interval at which to pulse pin (milliseconds)

    int pinState13 = LOW;                  // set pinState to 0

    unsigned long previousMillis13 = 0;    // store last time pin was updated

     

     

    const int pulsePin9 = 9;              // pin 9 @ 100ms

    const long interval9 = 100;           // interval at which to pulse pin (milliseconds)

    int pinState9 = LOW;                  // set pinState to 0

    unsigned long previousMillis9 = 0;    // store last time pin was updated

     

     

    const int pulsePin8 = 8;              // pin 8 @ 50ms

    const long interval8 = 50;            // interval at which to pulse pin (milliseconds)

    int pinState8 = LOW;                  // set pinState to 0

    unsigned long previousMillis8 = 0;    // store last time pin was updated

     

     

     

     

     

     

    void setup() {

     

        pinMode(pulsePin13, OUTPUT);

        pinMode(pulsePin9, OUTPUT);

        pinMode(pulsePin8, OUTPUT);

           

    }

     

     

    void loop() {

     

     

      unsigned long currentMillis = millis();

     

     

     

     

    //Pin13

      if (currentMillis - previousMillis13 >= interval13) {

        // save the last pulse time

        previousMillis13 = currentMillis;

     

     

        // if the pin is off turn it on and vice-versa:

        if (pinState13 == LOW) {

          pinState13 = HIGH;

        } else {

          pinState13 = LOW;

        }

     

     

        // set the pin with the pinState of the variable:

        digitalWrite(pulsePin13, pinState13);

      }

     

     

    //Pin9

      if (currentMillis - previousMillis9 >= interval9) {

        // save the last pulse time

        previousMillis9 = currentMillis;

     

     

        // if the pin is off turn it on and vice-versa:

        if (pinState9 == LOW) {

          pinState9 = HIGH;

        } else {

          pinState9 = LOW;

        }

     

     

        // set the pin with the pinState of the variable:

        digitalWrite(pulsePin9, pinState9);

      }

     

     

    //Pin8

      if (currentMillis - previousMillis8 >= interval8) {

        // save the last pulse time

        previousMillis8 = currentMillis;

     

     

        // if the pin is off turn it on and vice-versa:

        if (pinState8 == LOW) {

          pinState8 = HIGH;

        } else {

          pinState8 = LOW;

        }

     

     

        // set the pin with the pinState of the variable:

        digitalWrite(pulsePin8, pinState8);

      }

     

     

     

     

    }

     

    The results are the following:

    Pin 8: 50ms - 1m 15s per turn = 0.8RPM

    Pin 9: 100ms - 2m 30s per turn = 0.4RPM

    (I didn't take the time for 1000ms, it would take ages and I was happy with the consistency of the previous results)

     

    This gives us an inversely proportional relation of 40. Therefore, multiplying the required RPM value per 40 I can get the interval to set the program to give the required pulses.

     

    At this stage will limit the range to be set from 0.02 RPM to 5 RPM. Apparently, I don't need anything faster than 1 RPM but I might want to try the @EnricoMiglino suggestion injecting more gravity to the plants. I am not sure about the results but it sounds fun.

     

    As the drum will normally be set to under 1 RPM, seeing such small RPM values might be awkward so I am thinking to invert the value and have the input rotation value set as "Minutes per Turn". Accepting suggestions...

     

    Maybe in the future, we could have a database with the best turning speed for the different group of plants so it can be easily set once we start a new cycle.

     

    Below is a table with some values relating RPM, pulse width and minutes per revolution.

     

    RPM Pulse Width ms min/r
    5 8 0.2
    2.5 16 0.4
    2 20 0.5
    1 40 1
    0.8 50 1.25
    0.5 80 2
    0.25 160 4
    0.05 800 20
    0.02 2000 50

     

     

    After all the boring stuff you can relax having a glimpse of the drum turning at 0.8 RPM or 1.25 min/Turn

     


    0 0

    My outlet control is next on the list to fix up.

     

    What it was: (can you say nasty)

     

    What I need is a way to tell which kind of message came in.  Lets see what they look like.

     

    So if I can test for the existence of msg._session and msg.topic, I should be able to know which message came in and where to send out out.  So I took my existing function and added a new section, based off the fact if it is a MQTT or WS message.  Here is my function code now.

     

    if (msg._session) {    var jMsg = JSON.parse(msg.payload);    console.log(jMsg);    var nMsg = { payload: "0" }    if (jMsg.state == "on")        nMsg.payload = "1";           if (jMsg.outlet == "outlet1") {        return [null,null,null,null,null,null,null,nMsg];    }    if (jMsg.outlet == "outlet2") {        return [null,null,null,null,null,null,nMsg,null];    }    if (jMsg.outlet == "outlet3") {        return [null,null,null,null,null,nMsg,null,null];    }    if (jMsg.outlet == "outlet4") {        return [null,null,null,null,nMsg,null,null,null];    }    if (jMsg.outlet == "outlet5") {        return [null,null,null,nMsg,null,null,null,null];    }    if (jMsg.outlet == "outlet6") {        return [null,null,nMsg,null,null,null,null,null];    }    if (jMsg.outlet == "outlet7") {        return [null,nMsg,null,null,null,null,null,null];    }    if (jMsg.outlet == "outlet8") {        return [nMsg,null,null,null,null,null,null,null];    }
    }
    
    
    if (msg.topic) {
        var topic = msg.topic;       var nMsg = { payload: "0" }    if (msg.payload == "ON")        nMsg.payload = "1";           if (topic == "tower/outlet0001/control") {        return [null,null,null,null,null,null,null,nMsg];    }    if (topic == "tower/outlet0002/control") {        return [null,null,null,null,null,null,nMsg,null];    }    if (topic == "tower/outlet0003/control") {        return [null,null,null,null,null,nMsg,null,null];    }    if (topic == "tower/outlet0004/control") {        return [null,null,null,null,nMsg,null,null,null];    }    if (topic == "tower/outlet0005/control") {        return [null,null,null,nMsg,null,null,null,null];    }    if (topic == "tower/outlet0006/control") {        return [null,null,nMsg,null,null,null,null,null];    }    if (topic == "tower/outlet0007/control") {        return [null,nMsg,null,null,null,null,null,null];    }    if (topic == "tower/outlet0008/control") {        return [nMsg,null,null,null,null,null,null,null];    }
    }

     

     

     

    And now it looks like this.

     

     

     

    So much better. In 12-2 I wondered if HASS would do MQTT JSON switches and the answer is no. Also Home Assistant can use Web Sockets, so you could use Node-Red for your Home Assistant automation.  This is nice, because HASS's automation is clunky, limited, and you have to reload the config after each change.