Florian Echtler

Same here, smells a bit like Google blocked something?

Hi, author of the fork in question (https://github.com/floe/BLEPeripheralObserver) here - I've never used an RFduino, so I can't really suggest much. In theory, once scanning has started and a beacon...

Ah, didn't know about CurieBLE yet, I'll have a look. For the moment, I'll probably go with my hackish-but-works solution... no time for a proper solution, either ;-) BTW, PR...

P.S. The alternative would be to create a dedicated fork of your library that only supports the nRF5x series. Would probably be less work than rebuilding everything to fit the...

Came back to this after a couple of months, PR is now in a state where it's working fine for my specific use case. My suggestion would be to review...

Well, removing is probably too harsh, but how about splitting your library into a legacy branch that still supports the nRF8001, and a new branch that supports nRF51/52?

@cheeta1 sure, no problem, see `examples/observer/` in my master branch. It's a bit kludgy, but it demonstrates simultaneous sending and receiving of advertisements (i.e. broadcaster and observer in one).

@sandeepmistry if I rename my fork to, let's say, `BLEPeripheralObserver`, would that work?

OK, thanks. I don't have access to an nRF8001 at the moment, and the code looks quite ... involved ;-), so I'll leave this as-is at the moment.

Since I need a very specific and stable PWM frequency without interrupt jitter, I implemented an alternative version which works entirely in hardware, based on the PPI and GPIOTE peripherals....