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.

Messages - wookie1

Pages: [1] 2
Support / Re: bad Simblee batch?
« on: May 06, 2017, 12:20:50 PM »
The IC number is for Industry Canada certification, which is similar to the FCC in the US.

Are there release notes somewhere for the libraries so I can see what changed?

Support / Re: Simblee - OTA programming?
« on: November 22, 2016, 06:56:22 PM »
So if I read this right, there is no way to prevent someone from just writing another program on the Simblee device as long as Bluetooth is active? This is a pretty bad situation if that's true!

Support / Can't connect properly to Samsung Galaxy s6
« on: September 08, 2016, 07:09:06 PM »
I've got an app that interacts with a Simblee on Android. I've tested it successfully on an Android 4.4 tablet, an Android 6.0 phone, and an Android 5.1 Galaxy S4. I cannot get it to fully connect with a friend's Galaxy S6 which I think is also on Android 5.1. I have some LED's that the Simblee controls, and they flash when a connection is made. They flash when I try to connect with the Galaxy S6 but no communication will happen between the devices in either direction.

I used a sniffer and Wireshark to see what is happening. On the successful devices, the first communications I log with the filter btl2cap.cid==0x0004 (suggested by an Adafruit writeup) is:
Recvd Write Request, Handle: 0x000f
Recvd Write Response

On the Galaxy S6, there is a whole bunch of stuff before it gets to that, several lines below with different address ranges (can't seem to cut and paste from Wireshark):
Recvd Information Request, Handles: 0x001c..0xffff
Recvd Error Response  - Attribute Not Found, Handle: 0x001c

Then I see the two lines like in the successful cases from above, but then no additional communication is possible although the devices think they are connected still.

Support / Re: OTA use Android
« on: September 08, 2016, 06:46:07 PM »
I was getting ready to look into this also, was curious if any source code were available for Android and iOS DFU. I can't expect my customers to download the Nordic Toolbox and deal with figuring out how to get files loaded at the right time and everything.

Support / Re: Simblee - OTA programming?
« on: September 08, 2016, 06:44:42 PM »
How would you prevent other devices from connecting? Can't they just discover services and characteristics and be connected without further interaction? Since no real interaction is necessary to start DFU, how would you stop it? Is there any way to disable the auto-DFU enabling? I set up a command that when received by Simblee calls the OTA start, but I guess that's ignored then.

Android / Re: Simblee Android app - getting bumped again?
« on: August 10, 2016, 12:31:18 PM »
You must have missed the release announcement...

You might look at Codename One. They ported Cordova's BLE library, which is probably slow because it runs on the device's browser as I understand. Codename One takes code you write in Java, and then builds native Android and iOS application files. It's statically compiled, so it doesn't break when the browser is updated and probably runs faster also.

In general, BLE on Android has some challenges. There are a number of workarounds needed and you have to write some code to handle checking the Android API level and then calling different methods for scanning the device depending on the API level. Also, I think starting with level 23, you need to gain some permission from the user at runtime, not ahead of time like it used to be. On devices not running API level 23, you can't do that or it will crash (I've heard, I haven't gotten this far yet and still target API 21).

Good luck whichever way you choose!

Support / Re: BLE Sending Rate
« on: June 30, 2016, 12:36:40 PM »
What are you using to read the values on your phone? Is it the Nordic tools, or an app you created?

Are you sure of the state of the signal at the moment the digitalWrite happens? If you're reading some rapidly changing signal, BLE radio activity may happen at the time you think it would be reading, and you may be missing it.

What I mean is, the BLE radio acts like an interrupt that takes precedence over just about everything. What may be happening is that when your clock signal pin changes and your program is ready to read your data stream, the radio interrupt occurs and delays the reading a little. If you can, you might try something like this:



If the radio is active, this will wait until it is done before checking the clock and signal. You may still get an occasional clash if the radio was just about to be active so that you get through the while statement but not all the way through the digitalReads and whatever else, but it won't be that frequent if the time-critical code is short and fast.

Support / Re: Simblee - How to measure analog inputs up 5V?
« on: June 06, 2016, 09:17:23 AM »
I think that approach would kill the Simblee device, it can only handle up to a max of about 3.5V (I'd stick to 3.3V to allow for noise or transients). There are a couple of ways to handle this, though. You can create a voltage divider to reduce the 5V, or you can add a differential amplifier or instrumentation amplifier. These devices basically re-map a signal from one voltage rail to another. What that means is that on one side of the chip, you'll connect ground, 3.3V, and an output to your Simblee. On the other side, you'll connect 5V, ground, and your 0-5V signal. Then, whatever fraction of the full 5V is present on the 0-5V signal will be output as the same fraction of 3.3V on the other side to the Simblee.

Example: if you had 1.67V on the 0-5V side (33% of the full 5V), the output to the Simblee would be 1.1V (33% of 3.3V).

An added benefit of this is electrical isolation, which will decouple the Simblee from the noise coming in on the 0-5V wire.

For the voltage-divider approach, you just need something like a 10K and 20Kohm resistor divider, so you'd have Simblee -> 10K -> 0-5V -> 20K -> Ground. If accuracy is important, though, this approach isn't ideal. The actual resistances would need to be measured and their resistances also change with temperature. I'd use the first approach for anything requiring accuracy.

iOS / Re: Anyone tried writing an RFduino app with Xamarin?
« on: May 23, 2016, 01:10:02 PM »
I used Codename One, another app development platform that you write most of the code in Java and then can build native app files for Android, iOS, etc from one code base. It wasn't that difficult. In CN1, I did have to write the native code for the BLE part, but I found some good examples for each platform. Then in CN1 you can link it all together so it builds it into the app. I'm not a professional developer, and didn't know much when I started (not even Java), but it wasn't too hard.

I'm pretty sure Xamarin users have created libraries for BLE as well.

Simblee Libraries / Re: SimbleeBLE affects TIMER1/2 accuracy
« on: May 17, 2016, 09:43:40 PM »
I gave up on trying to use timers with Bluetooth on. The bt radio takes precedence over all other functions and interrupts. I ended up using an ATTiny85 to handle some frequency counting and communicate with it over I2C.

Simblee Announcements / Re: Simblee
« on: May 04, 2016, 07:57:31 PM »
I'm getting to a point where I want to narrow down a module selection for a product. I've built prototypes with RFduino but would prefer to move to Simblee for its size and OTA program flashing capability. The problem is the Bluetooth product registration. I believe I need to get the QDID numbers for the module so I can register it and be licensed. I haven't been able to get a response on this from RF Digital yet, has anyone looked into this? I see on the Bluetooth SIG website that the RFduino QDID's are listed. I don't want to spend the $$$$ to register an RFduino to then switch to Simblee and pay more $$$$, but I don't know how long I need to wait on Simblee info.

Support / Re: EEPROM/Flash
« on: April 29, 2016, 06:51:32 PM »
Instead of while (RFduinoBLE.radioActive)  {}, you need while (!RFduinoBLE.radioActive)  {}

Basically I think this burns time until the radio is active, at which time the radio will interrupt your code, and then when the radio is done the next line of your code will start, which will give you the maximum amount of time between advertising events.

Pages: [1] 2