TinyCircuits

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Andy

Pages: [1]
1
General Discussion / TinyScreen+ and Wifi Board
« on: February 07, 2017, 06:50:39 PM »
I'm unable to get the wifi board to be recognized by a TinyScreen+. I can use the same wifi board on a tinyDuino with the CC3000 code and get it to operate client or server, but no joy when using wifi101 on a tinyScreen+. Here is the FW Check that I tried amongst other things, if someoen can see a problem, do let me know. Thanks.
==================
#include <SPI.h>
#include <WiFi101.h>

#define USB_SERIAL

#if defined(USB_SERIAL)
  #define SerialOut SerialUSB
#else
  #define SerialOut Serial
#endif

void setup() {
  WiFi.setPins(8,2,A3,-1);
  SerialOut.begin(115200);
  delay(1000);

  SerialOut.println("WiFi101 FW check.");
  SerialOut.print("WiFi101 shield: ");

// **** the board is not found, we get "NOT PRESENT" ****
 
  if (WiFi.status() == WL_NO_SHIELD) {
    SerialOut.println("NOT PRESENT");
    return; // don't continue
  }
  SerialOut.println("DETECTED");

  String fv = WiFi.firmwareVersion();
  SerialOut.print("FW version installed: ");
  SerialOut.println(fv);

  // Print required firmware version
  SerialOut.print("FW version required : ");
  SerialOut.println(WIFI_FIRMWARE_REQUIRED);

  // Check if the required version is installed
  SerialOut.println();
  if (fv == WIFI_FIRMWARE_REQUIRED) {
    SerialOut.println("Result: PASSED");
  } else {
    SerialOut.println("Result: NOT PASSED");
    SerialOut.println(" FW version too low.");
  }
}

void loop() {
  // do nothing
}

2
General Discussion / Locked up TinyScreen+ (need help)
« on: January 29, 2017, 05:17:11 PM »
I am hoping there is a factory reset or method to halt an upload when the board is powered (so I can clear / replace what I uploaded).

What I uploaded has some code in the loop which causes the board to get stuck (ie: an infinite loop). Thus the TinyScreen+ does not show up as a USB recognizable device, and I can not upload anything to it.

Anyone know how to clear this situation?

Thanks

3
TinyDuino / TinyScreen+ and SD board
« on: January 19, 2017, 10:56:49 AM »
I am working on something where I need to have a microSD board.

I have a tinyScreen+ and an SD board only so far. If I do any calls the the SD library, everything locks up and everything is dead. I can recompile, reload etc... I can read buttons and everything, but again, once I try to create a file or read a directory the whole thing locks up.

I've verified this with serial comms to do println debugging and it is 100% reproducible.

This is the lib I am using:

https://www.arduino.cc/en/Reference/SD

If anyone has any suggestions on how to get this beyond a lockup and can share, very much appreciated.

4
General Discussion / Worlds Smallest Diabetic Monitor Using Tiny Circuits
« on: January 08, 2017, 09:27:20 PM »
This is more a shout out to Tiny Circuits than anything for making such an awesome platform.

As I was looking for a tiny full featured platform I jumped on the Tiny Circuits platform for prototyping! I love these things. Part of me wants to shout this out as the folks running Tiny Circuits don't have time to do this kind of thing, they are running a business, and I commend them for it (I've run shops and it is not easy).

My first creation with tiny circuits is the worlds smallest Diabetic Glucose monitor (CGM).

The basics of this are that the body worn sensors data is sent to a server (that is the CGM vendors stuff). From there, I pull it down to an android device, and send the data via BLE to a TinyScreen+ with a BLE board and battery.

The Articles can be found here:

Part 1:
https://www.linkedin.com/pulse/building-worlds-smallest-diabetic-cgm-receiver-part-1-andy-pal?trk=hp-feed-article-title-publish

Part 2:
https://www.linkedin.com/pulse/building-worlds-smallest-diabetic-cgm-receiver-part-2-andy-pal?trk=hp-feed-article-title-publish

There will be a #3 in the series as the enclosure issue has finally been solved. And more coming yet using these excellent devices ( I have a full series of tiny medical devices in mind!).

Cheers and happy new year all!

Andy



5
TinyLily / Communications
« on: January 04, 2017, 07:00:58 PM »
Are there any comms for the TinyLily boards? BLE perhaps?

I am thinking of medical jewelry for sensing and/or display.

6
My wife has been looking at "dog tracking" for our 2 dogs, however everything out there requires a monthly subscription. We do not want huge range and a cell tower connection.

A simple solution using Tiny Circuits would be to use a CPU board, GPS module and the low frequency board as it can do up to 1/2 mile (depending on obstacles, humidity etc..). The device would only send (less power usage). It would sleep for a period of time, read the gps and fire out the Lat/Long string.

On the other side, another CPU board with radio board in listen mode could send the received data via a BLE board to an Android phone which would parse the string and plunk the location onto a map.

Only risk is battery life on the "dog" unit, so a low duty cycle and send only would be necessary, and no UI to push.

7
TinyDuino / Can the name be changed for BLE scan?
« on: December 28, 2016, 04:25:08 PM »
From an android phone, when I scan the Tinyscreen+ publishes a name of "URT". I've grepped the example project and am unable to locate that string. Is it possible to change the name for a  BLE scan?

Thanks,
Andy

8
General Discussion / Desoldering switches
« on: December 22, 2016, 01:59:40 AM »
A quick question before I do this.

Any heads up before I desolder the switches on the TinyScreen+? I need to remove them, solder on leads that go to momentary switches that will be on the enclosure I will be making. I am unable to add a breakout board and tap off of that as I am keeping the profile as low as possible.

Thanks in advance if anyone has a "watch out for this..."

9
TinyDuino / TinyScreen+ and NFR8001
« on: December 20, 2016, 04:03:36 AM »
I've been trying (rather unsuccessfully) to get BLE working with the tinyScreen+. I've tried the tutorial (BLE), however under boards it does not list the TinyScreen+. I've downloaded the tutorial (NFR_Nordic_BLE*) and it won't even compile as it it thinking AVR.

Do these devices work together? If so, is there an ETA on sample /example? I've been hacking some stuff up, and can't even get things to compile right (see other post regarding compile errors) but being new to the platform etc... makes it an unpleasant slog.

I have a functional CGM receiver (falls under class 2 FDA, secondary display) put together since last week, but the form factor is far too thick to be usable due to multiple boards and was hoping to use the TinyScreen+ as it put the physical size into a good shape for the enclosure. My intent was a prototype by Jan 9th.

10
TinyDuino / Error during compile Question (Tinyscreen+)
« on: December 20, 2016, 12:48:26 AM »
Hopefully someone has seen this and knows the fix on it.

I am bolting a TinyScreen+ and the BLE board together. I am reusing what I did a few days ago. That used the watch HW set. I am trying to reduce thickness, thus the TinyScreen+.

The tinyScreen+ works fine on it's own.

The other board set works fine with what I put together based on the watch code example (lots of cannibalization).

I've added #define __SAM3X8E__ to the top of hal_aci_tl.cpp so the compile doesn't start trying to bring in the avr HW includes.

When I try to take my new code base and compile it for the tinyScreen+ & BLE board I get the following errors, if anyone has seen this and knows the fix and can pass it along, it would be very much appreciated.


==========================

Arduino: 1.6.12 (Windows 8.1), Board: "TinyScreen+, Default"

In file included from sketch\hal_aci_tl.h:46:0,

                 from sketch\aci_queue.cpp:26:

aci.h:265: error: 'uint16_t' does not name a type

   uint16_t min_conn_interval;   /**< Minimum connection interval requested from peer */

   ^

aci.h:269: error: 'uint16_t' does not name a type

   uint16_t max_conn_interval;   /**< Maximum connection interval requested from peer */

   ^

aci.h:273: error: 'uint16_t' does not name a type

   uint16_t slave_latency;       /**< Connection interval latency requested from peer */

   ^

(**** bunch of stuff removed to get below the 20,000 char max limit for posts****)

aci_queue.cpp:188: error: 'struct aci_queue_t' has no member named 'head'

   memcpy((uint8_t *)p_data, (uint8_t *)&(aci_q->aci_data[aci_q->head % ACI_QUEUE_SIZE]), sizeof(hal_aci_data_t));

                                                                 ^

aci_queue.cpp:188: error: 'memcpy' was not declared in this scope

   memcpy((uint8_t *)p_data, (uint8_t *)&(aci_q->aci_data[aci_q->head % ACI_QUEUE_SIZE]), sizeof(hal_aci_data_t));

                                                                                                                ^

exit status 1
'uint16_t' does not name a type

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
 

11
General Discussion / New User
« on: December 14, 2016, 12:16:52 AM »
Hi there,

New to the platform and new to the forum. I received my initial kit 2 days ago (very well done design).

My goal / intention is on medical applications. I make class 1 through class 3 medical devices in several fields. I have a few items I am looking at prototyping.

I am roughly 30 to 40% of the way through to the first rough prototype.  I am using the setup to operate as a very small display for a continuous glucose monitor (CGM). The CGM is a class 3 PMA device which counts the ions shed off of a glucose / glucose oxidase reaction. These "counts" are aggregated for a period of time, then correlated to a blood sugar value. The device is a body worn sensor which reports wirelessly. A secondary display like I am putting together is class 2. I should have this proto complete and fully operational soon. It will be regular open boards at first. Once my next order arrives (I just put it in), I will use the reduced stack height to build the entire system into a keychain fob.

The goal is to give a diabetic a keychain fob that reports their blood sugar and trend every 5 minutes.  I may add a small pancake motor to draw attention for alerts. Then I will move onto the next device in the queue.

I can see these little systems being great for many practical purposes.

Suggestion:

Ribbon Cable Extenders: Can a person get them in short lengths? I am thinking in the range of 1 to 2 inches. I would need this for a later medical prototype.

Pages: [1]