Recent Posts

Pages: [1] 2 3 ... 10
Oak Support / Re: ESP32 in the wild
« Last post by Solice on Today at 04:47:32 am »
I would totally buy into that.  One of the major advantages of the ESP32 over the ESP8266 is that there are two microcontroller cores; one to deal with wifi events and one to deal with user code simultaneously.  This basically means there's no (or much less) chance of the MCU crashing or dropping signal due to user code tying keeping it too busy to deal with wifi events.

The major problem with the ESP32 right now is not lack of hardware in the channel, it's library development... so if Erik made an Oak Pro or something, that's where a lot of work would end up going if he wants to push some units.  Another thing would be to sell it cheaper than the competitors.  The Sparkfun ESP32 Thing is about twenty bucks, and the generic Ebay units are about seven.  He would have to be able to turn a profit somewhere in the middle.
Oak Support / ESP32 in the wild
« Last post by PeterF on January 21, 2017, 06:51:07 pm »
Ok, I know this isn't the support forum for the ESP32, but I couldn't resist posting this as the ESP8266 is the heart of the Oak, and this is it's big brother... so maybe this will be the heart of the Oak v2 (if there is one)? :-) Plus those of us on this forum should be interested in things ESP8266/32/WiFi generally! :-P
DigiX Support / Re: DigiX SMOKE! (Dead R.I.P.)
« Last post by PeterF on January 21, 2017, 04:02:18 pm »
Well... what have you got to lose (other than a little bit of time and money)? :-P It might be worth it just for the experience.

As far a bootloading... IIRC, because this is a SAM3X based board, the bootloader is pre/hardcoded into the ROM at the factory (SAM-BA), so it shouldn't be an issue.

@Solice: I meant to mention earlier - the DFPlayer modules seem pretty good... I'm just using them for looped music playback so far, and they sound ok, and they do have some peculiarities to work around (such as any serial information requests made whilst they are playing will make the audio skip for a moment whilst it processes the data :-/), but you can relatively easily work around that by waiting for it to gell you want's going on, not the other way around... I could see a Digispark controlling them without too much drama... making real compact throwaway designs :)

Edit: I don't know if either of you find this interesting... it popped up in today's news feed, and is probably the smallest SAM/ARM development/breakout board I've seen so far ;)
DigiX Support / Re: DigiX SMOKE! (Dead R.I.P.)
« Last post by exeng on January 21, 2017, 09:31:38 am »
PeterF... you ask:
So when will the funeral be exeng... or will you just finish the half-commenced cremation?

Well, as soon as I stop staring at the board and imagining lifting the MC and putting down a new one. Probably not cost effective as the MC is about $10, and a ChipQuick removal kit is about $15, all Sans shipping. Then there is the skill required to pull this off (no pun intended), and then successfully put down the new MC. Finally, don't know if the MC needs any boot loader programming. But can't help dreaming about it.

It's really difficult to let my DigiX go.
DigiX Support / Re: DigiX SMOKE! (Dead R.I.P.)
« Last post by PeterF on January 20, 2017, 11:31:08 pm »
 ;D ;D ;D

Well, as long as yours is nice and toasty also, then all's good... I got ambient of temperatures of 33C at the moment... so that won't be helping! ;)  I was hoping to avoid the datasheet (at 1459 pages it's a wee bit longer than the 660 of the Atmega328  ... which is long enough for me :D ), but looks like I'm out of luck if I do want to drop the temp... as you said... there should be a fuse setting, or hopefully a runtime function/variant possibility so it can clock up and down as needed by the application (not that I have had much luck seeing if there is something for the Due, let alone the DigiX).

Thanks for that... I'll probably keep on with the AVR or Teensy + Oak approach then for that sort of low power + WiFi capability
DigiX Support / Re: DigiX SMOKE! (Dead R.I.P.)
« Last post by Solice on January 20, 2017, 09:18:31 pm »
Hrm.. about an hour or so of being on, and it gets up to 95 F (35 C) according to the IR gun.  Not dangerous, but certainly shows there's some wasted power somewhere.  It seems that the warmest part is the MCU itself, so I'm not sure what to do about that.  I'm not well read on this chip.  It's an Atmel chip, so there could be fuses.

I was going to look this up for you, but the datasheet appears to have hundreds of pages, and it's getting late.  Good luck!
Digispark Projects / Digispark DuckyScript Compiler
« Last post by uslurper on January 20, 2017, 08:48:58 pm »
Hey everyone,
I wrote a little python program that converts DuckyScript for the Hak5 USB Rubber Duck into a form usable by the Digispark. It even escapes strings properly for you.
The code can be found at, or you can download it through pip (pip install digiduck).

Also, since the code is output in plaintext, you can add any control flow or I/O you want after it's converted, which is nice.

It works pretty well so far, but I'd really appreciate any feedback or bug reports you have.

Oak Support / Re: Oak with data dashboards
« Last post by PeterF on January 20, 2017, 08:24:22 pm »
Ok, I've had a quick look at the code, and made a few changes (probably just due to smooshing differnt bits of code together)...  I got rid of the WiFiClient client; from loop(), as it's already (properly) declared globally (at the top).

Can I ask why the multiple

Code: [Select]
  if (Particle.connected() == false)

checks... one in setup, and two in loop? It shouldn't really be needed, because unless you have the Oak in SYSTEM_MODE(SEMI_AUTOMATIC) or SYSTEM_MODE(MANUAL), the Oak's firmware will handle that itself in the background. When I've used Particle variables, that is what I have done... used SYSTEM_MODE(SEMI_AUTOMATIC) so that the Particle connection needs to be manually established, so that I can declare the variables and then use that conditional statement to connect to Particle.

Do you want it to delay for 60 seconds and then send the temperature updates, or send the first updates straight away and then wait 60 seconds until the next?

As to why the Oaks stop responding... do they stop responding completely (i.e. offline on Particle) or just stop sending data to ubidots? Do they reboot into safe mode on their own? Nothing is jumping out from the code... it all looks fine. I have essentially this code running on another Oak that has been running for a couple of months now, and it has been stable, but there is one big difference... it isn't running 24x7... it is running, and putting itself to sleep until the next update, at which point it reboots and starts afresh each time. Would that be practical for your intended use? It does mean that you need to put it into config mode to do OTA programming, as it really is asleep during wait... but on the plus side power consumption is virtually nothing.

The only other big difference is that I have the functions for reading the DS18B20 directly in my code (I only include OneWire), but that shouldn't really be the cause of the problem.

If you do want to go down the sleep / reboot route... do a   

Code: [Select]
// power save/sleep for 1 minute
ESP.deepSleep((60 * 1000000), WAKE_RF_DEFAULT);

at the end of your loop, and remove the earlier delay. You'll also need to connect P10 [WAKE] to RST so that the Oak can wake itself up at the end of the deepsleep interval.

Code: [Select]
#include <OneWire.h>
#include <DallasTemperature.h>
#include <WiFiClient.h>
#include <ESP8266WiFi.h>

/*-----( Declare Constants and Pin Numbers )-----*/
#define ONE_WIRE_BUS_PIN 2

/*-----( Declare objects )-----*/
// Setup a oneWire instance to communicate with any OneWire devices
OneWire oneWire(ONE_WIRE_BUS_PIN);
// Pass our oneWire reference to Dallas Temperature.p,
DallasTemperature sensors(&oneWire);
WiFiClient client;

/*-----( Declare Variables )-----*/
DeviceAddress Probe01 = { 0x28, 0xFF, 0xA4, 0xD9, 0x62, 0X16, 0x04, 0x3B };
DeviceAddress Probe02 = { 0x28, 0xFF, 0xA9, 0xD9, 0x62, 0x16, 0x04, 0xD7 };
double temp1, temp2;
String tubi1 = "xx1";
String tubi2 = "xx2";
String token = "tttt";

void setup()   /****** SETUP: RUNS ONCE ******/
  // start serial port to show results
  Serial.print("Initializing Temperature Control Library Version ");

  // Initialize the Temperature measurement library

  // set the resolution to 10 bit (Can be 9 to 12 bits .. lower is faster)
  sensors.setResolution(Probe01, 10);
  sensors.setResolution(Probe02, 10);

  Particle.variable("temp1", temp1);
  Particle.variable("temp2", temp2);

  if (Particle.connected() == false)

}//--(end setup )---

void loop()   /****** LOOP: RUNS CONSTANTLY ******/
//  if (Particle.connected() == false)
//  {
//    Particle.connect();
//  }
//  if (Particle.connected() == false)
//  {
//    Particle.connect();
//  }
//  delay(60000);
  // Command all devices on bus to read temperature

  Serial.print("Probe 01 temperature is:   ");
  temp1 = sensors.getTempC(Probe01);
  updateUnidots(temp1, tubi1);

  Serial.print("Probe 02 temperature is:   ");
  temp2 = sensors.getTempC(Probe02);
  updateUnidots(temp2, tubi2);

  // power save/sleep for 1 minute
  ESP.deepSleep((60 * 1000000), WAKE_RF_DEFAULT);
}//--(end main loop )---

void updateUnidots(double value, String idvariable)
  // if you get a connection, report back via serial:
  int num = 0;
  String var = "{\"value\": " + String(value) + "}";
  num = var.length();
  if (client.connect("", 80)) {
    client.println("POST /api/v1.6/variables/" + idvariable + "/values HTTP/1.1");
    client.println("Content-Type: application/json");
    client.println("Content-Length: " + String(num));
    client.println("X-Auth-Token: " + token);

//*********( THE END )***********
DigiX Support / Re: DigiX SMOKE! (Dead R.I.P.)
« Last post by PeterF on January 20, 2017, 07:46:42 pm »
Yumyum? I hope that one is doing something food related! :-P

So when will the funeral be exeng... or will you just finish the half-commenced cremation?  :o

I just powered my DigiX via the 3v3 pin with a stable 1A capable supply, and it appears that the WiFi side can't be powered that way... it was drawing somewhere around 100-120ma @ 3v3, and didn't connect to my router. I then powered it via USB (so 4.7-5v) and it is now pulling 180-220ma (oh wait... that may also be the onboard led blink... is running the blink sketch IIRC and is in time with the surges).  Pull the WiFi enable jumper, and it is 130-170ma). There was a minor drop in power consumption when I tried the same when powering via 3v3, but only 10-15ma, so not sure what to make of that.

Maybe solice can help me with this though, since he has a number of DigiXs in captivity... does your MCU get hot? Like, put your finger on it after it has been running for a few minutes and it is noticeably hot? And even if you shove a heatsink on it, it still does a good job of warming the heatsink up? Do you know if it is possible to lower the clock frequency (easily!) to reduce heat/wasted power? That was the main think that made me decide to use a teensy / Atmega328 + Oak for one or two other projects instead of the DigiX... I wanted to use it for the wifi + nrf + oodles of memory, but then it just seemed a power hog.
Oak Support / Re: Does Oak have AP mode/server support?
« Last post by digi_guy on January 20, 2017, 06:44:08 pm »
Using the Oak in AP mode is pretty easy, check out this thread for an example I wrote that had two Oaks talking to eachother.,2171.msg10125.html#msg10125

Pages: [1] 2 3 ... 10