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 - Tim

Pages: [1] 2 3 ... 7
1
Simblee Libraries / Re: SimbleeBLE affects TIMER1/2 accuracy
« on: March 19, 2017, 08:38:05 PM »
Hi Jeff,

Yes, micros() is inaccurate when BLE is on due to priority of the BLE stack. That's what led me to use PPI, GPIOTE and TIMERs because they are not subject to CPU or BLE. Not sure about delayMicroseconds(), but I presume same issue. micros() is just reading the value of RTC1, so if you could use PPI and GPIOTE to start and stop RTC1 and read it's value in an interrupt routine, that might do the trick. I don't have much experience with encoders, so I might be way off here.

I'm very interested to hear RFDigital's response. If you're using PPI, GPIOTE and TIMERs to "handle encoder interrupts," my understanding is it should work.

Thanks for adding to the conversation.

Tim

2
Simblee Libraries / Re: SimbleeBLE affects TIMER1/2 accuracy
« on: March 17, 2017, 09:58:08 PM »
Hi Jeff,

With this line:

attachPinInterrupt(EXTERNAL_ENCODER, encoderPulseCount, HIGH);

I presume you want encoderPulseCount to be called when pin EXTERNAL_ENCODER goes HIGH, correct? I don't know why it's causing SFM to break.

You could try using GPIOTE to fire the GPIOTE_IRQn interrupt routine for both throttlePin going high to low and EXTERNAL_ENCODER going low to high. You would add this code:

Code: [Select]
NRF_GPIOTE->CONFIG[2] =  (GPIOTE_CONFIG_POLARITY_LoToHi << GPIOTE_CONFIG_POLARITY_Pos)
              | (EXTERNAL_ENCODER << GPIOTE_CONFIG_PSEL_Pos)
              | (GPIOTE_CONFIG_MODE_Event << GPIOTE_CONFIG_MODE_Pos);
NRF_GPIOTE->INTENSET = GPIOTE_INTENSET_IN2_Msk;

Then instead of having two interrupt routines (reportTime and encoderPulseCount), you would have a single interrupt routine that would test which interrupt has fired and then call either reportTime or encoderPulseCount.

Code: [Select]
if (NRF_GPIOTE->EVENTS_IN[1] == 1) {
   NRF_GPIOTE->EVENTS_IN[1] = 0;
   reportTime();
} else if (NRF_GPIOTE->EVENTS_IN[2] == 1) {
   NRF_GPIOTE->EVENTS_IN[2] = 0;
   encoderPulseCount();
}

With my limited experience, this is what I would try.

Maybe others will have suggestions.

Tim

3
Simblee Libraries / Re: SimbleeBLE affects TIMER1/2 accuracy
« on: March 12, 2017, 02:45:38 PM »
Hi Jeff,

It would be helpful to see some code, even if just the standalone code. I'm not experienced with PWM but I've learnt the whole PPI mechanism of Simblee/RFduino and happy to assist if that's where your issues lie.

Tim

4
Support / Re: Simblee - OTA programming?
« on: January 30, 2017, 05:53:22 PM »
Hi ...

A bit of info to share that might be helpful.

We hand assemble our boards too using the following providers:

- PCBs manufactured by OSH Park (https://oshpark.com)
- stainless steel stencils by OSH Stencils (https://www.oshstencils.com)
- reflow oven by Whizoo (http://www.whizoo.com)

Our board provides access to UART pins (see image1). We use a 5-pin header to hold onto to PCB while programming occurs. Wires from this header are connected to 7-pin header which connects to the USB shield. We connect everything, hold the 5-pin header inserted into the UART access point on the board, then initiate programming from the Arduino IDE (see image2).

I agree, it would be convenient if Simblee shipped with the OTA bootloader onboard so initial programming could occur OTA.

Your sketch does not need to call ota_bootloader_start() when using the Nordic iOSDFULibrary. All that's necessary is that your sketch include ota_bootloader.h. OTA can be initiated by the iOS app connected to the Simblee via BLE.

Hope helpful ...

Tim

5
Support / Re: Simblee - OTA programming?
« on: January 04, 2017, 05:43:13 PM »
This is very helpful Stephen. Thank you.

Just yesterday I got the following to work (I'm on Mac OS 10.11.6):

- Successful installation of nrfutil (0.5.2) and generation of .zip for my sketch .hex file.

- Successful integration of Nordic's iOSDFULibrary using the Cocoapods method (see documentation here: https://github.com/NordicSemiconductor/IOS-Pods-DFU-Library/blob/master/documentation.md).

- Connect to Simblee advertising in BLE mode, then perform OTA sketch update by calling DFUServiceInitiator.start().

Our app does store user-defined data in flash and currently uses page 203 (user-defined data is erased during OTA). I will try pages 230, 235, or 237. It will be very helpful if user-defined data is not erased during OTA.

Cheers,

Tim

6
Support / Re: Simblee assembly
« on: November 29, 2016, 07:01:57 PM »
Yes we buy from DigiKey, usually 50 at a time. They ship to Canada for $8 (2nd day) and never are we charged duty, brokerage. We too hope the price goes down but currently the economics are okay for our product.

Also, regarding hand assembly and Simblee shifting, we seems to have solved by using a USB microscope to more precisely position Simblee before boards go in the oven for reflow.

Good luck.

Tim

7
See here about using both BLE and COM:

http://forum.rfduino.com/index.php?topic=1357.0

Tim

8
Simblee Libraries / Re: SimbleeBLE affects TIMER1/2 accuracy
« on: November 16, 2016, 12:48:49 PM »
This is a long-overdue post to this thread. Simblee library 1.1.0 included support for the following calls:

SimbleeBLE_requestHFCLK();
SimbleeBLE_checkHFCLK(&isRunning);

After calling SimbleeBLE.begin(), run this code to request the hi frequency clock:

  uint32_t isRunning = 0;
  SimbleeBLE_requestHFCLK();
  // Wait for the crystal to startup
  while (!isRunning) {
    SimbleeBLE_checkHFCLK(&isRunning);
  }

TIMER1 and TIMER2 then benefit from the increased accuracy of the HFCLK.

Tim

9
Simblee Libraries / Re: Avoid DFU mode entry at start of sketch
« on: November 10, 2016, 09:19:34 AM »
I experienced the same. See:

http://forum.rfduino.com/index.php?topic=1355.msg5030#msg5030

Never did resolve. I got an RFD77203 (29-pin GPIO Breakout) and changed photoTransistorPin to 9 and all behaves normally.

Tim

10
Support / Re: Simblee assembly
« on: September 29, 2016, 12:57:21 PM »
Thanks Tolson.

Sure would be nice to learn of a reliable way to solder Simblee. It can be expensive at $30 a crack (plus board and other components) if unable to fix the shift, not to mention the time.

I tried to repair a shifted chip in much the same way you did. I was able to position it properly, program the chip (including OTA boot loader), but it always starts up into DFU mode, which times out in 15 seconds and then our sketch boots. I speculate that there's now a solder bridge on some pins, perhaps under the chip where not visible. (I've experienced some odd issues relating to OTA where if I used certain GPIO pins for I/O, same thing would happen - Simblee always booted into DFU mode. When I switched to other pins, normal operation. Strange.) I tried to simply reflow the board hoping that any solder bridges or issues would resolve. No go.

I wonder if the issue is due more to the unbalanced number of pins on the long sides of Simblee, perhaps causing differing amounts of surface tension on each side when reflow occurs. If this is the case, a solution feels difficult to me. How do pick-and-place machines manage to get consistent results?

What about lead versus lead-free solder paste? We use MG Chemicals lead-free.

What about somehow clamping the chip in place to physically preventing shift?

Our product is a niche product. We may sell a few thousand over time. We're planning to hand assemble the first 100 or so before considering automating. So this is a major issue for us to resolve. Hopeful ...

Thanks for any advice, creative thoughts :).

Cheers,

Tim

11
Support / Re: Simblee assembly
« on: September 28, 2016, 12:44:02 PM »
Posting a little feedback from other sources.

It may be that the solder paste for the four large ground pads on the bottom of Simblee (pins 42-45) starts to reflow, flux bubbles could potentially raise the chip and cause the shift. We're going to try manually applying a very small amount of flux to those pads and watch the results.

I've also heard from RF Digital that if you connect the ground pins 1, 2, 4, 6, 19, 30 to ground on the PCB, there's no need to connect the large pads (pins 42-45) to ground also. All ground pins on our board are connected to ground, so if we find the issue to be too much paste on the pads for pins 42-45, we'll modify our board for the next batch to remove the pads altogether.

Also have heard that these could also be contributing factors to the issue:

- inaccurate placement of the chip
- the level of the boards being out
- uneven distribution of heat in the reflow oven

Will post more info here as we learn ...

Thx,

Tim

12
Support / Re: Simblee restarts after "SimbleeBLE.end()"‏
« on: September 27, 2016, 06:20:16 PM »
Hi ...

This prompts a question. I'm calling SimbleeBLE.end() and SimbleeBLE.send() inside the SimbleeBLE_onReceive callback (depending on the message content received). All appears to work fine. Even though, should I move the SimbleeBLE.end() and SimbleeBLE.send() calls out of SimbleeBLE_onReceive and into loop? In Simblee_onReceive I can set a bool to true and test it in loop (and set it back to false) and place the SimbleeBLE.end() or SimbleeBLE.send() calls there.

Thoughts?

Thanks,

Tim

13
Support / Re: RfDuino reboots when I attempt to write to Flash...
« on: September 27, 2016, 06:08:39 PM »
Hi  ...

This is from a long time ago, so perhaps resolved.

I had the same issue, now using Simblee, and resolved by examining the first few bytes of each flash page to see where my sketch and the Simblee OTA boot loader is stored.

Code: [Select]
void write_flash_contents() {
  Serial.begin(9600);
  for (i=124;i<252;i++) {
    char *p = (char*)ADDRESS_OF_PAGE(i);
    Serial.print(i);
    Serial.print(" ");
    int j;
    for (j=0;j<9;j++) {
      Serial.print(p[j],DEC);
      Serial.print(" ");
    }
    Serial.println(p[9],DEC);
  }
 }
}

You need to run this code before you write any data to flash. Then choose a page that's not used. I use page 203 and all works fine.

Tim

14
Support / Simblee assembly
« on: September 26, 2016, 10:14:40 PM »
Hi all,

Writing to share some experience and ask a question. For our product, we are hand-assembling the first 100 or so units. We get our PCBs from OSHPark. We use a stencil from OSHStencil and we're reflowing with a Whizoo reflow oven. Here are some links:

https://oshpark.com
https://www.oshstencils.com
http://www.whizoo.com

This is working very well except occasionally (1 of 10 boards), the Simblee shifts a bit during the reflow process. I've attached a few photos.

Any thoughts on why this is happening? Normally during reflow, parts will shift into place not out of place. The oven may not be precisely levelled. I wonder about the solder paste connecting the four ground pads under Simblee? When it reflows, could it cause the shifting? Maybe reduce the amount of paste on those pads?

Thanks for any thoughts, advice.

Tim

15
Support / Re: Lilypad Simblee - Usage without Simblee App?
« on: August 15, 2016, 11:04:43 AM »
Hi James,

If you posted some of your Core Bluetooth code, I could take a look.

Tim

Pages: [1] 2 3 ... 7
anything