BlueBasic: BASIC for Bluetooth

Description

This project contains a BASIC interpreter which can be flashed onto a CC2540 or CC2541 Bluetooth module. Once installed, simple use the Bluetooth Console tool to connect and start coding on the device using good old BASIC.

The project was inspired by experimenting with the HM-10 modules (a cheap BLE module) and a need to provide an easy way to prototype ideas (rather than coding in C using the very expensive IAR compiler). Hopefully other will find this useful.

Software: https://github.com/aanon4/BlueBasic

Details

Introduction

Blue Basic is a heavily modified port of the TinyBasic interpreter developed to run on the Texas Instruments CC2540 and CC2541 Bluetooth LE chips (BLE) (see http://www.ti.com/product/CC2540 and http://www.ti.com/product/CC2541).

Motivation

If you want to develop code for these chips you have to buy a compiler. The compiler is from IAR Systems and, while it is quite a nice compiler as embedded development goes, it also costs $3,500!! Yes, they do a kickstart version but the code size is far too small to compile even the basic BLE stack from TI, let alone any code you might want to add. There are various low-cost solutions to this problem. One popular option is to buy the device with pre-programmed software, and use it with an Arduino system. There are some very nice devices based on this idea such as the LightBlue Bean (http://punchthrough.com/bean/) from Punch Through Design. But fundamentally the BLE chip is more than capable of running any program you might put on the Arduino; so this seems like a waste. Then there's power consideration, complexity and cost of adding the extra processor.

But finally, and personally, this is just annoying. There's no reason, other than cost, that everyone shouldn't be able to by a cheap BLE chip and program it the way they want for free. That's what Open Software and Open Hardware is about.

Alternative

I have a history of writing interpreter and virtual machines for small device, including the first open source Java VM "Kaffe" (https://github.com/kaffe/kaffe), the original Javacard implementation and the first .NET VM used in smartcards. It seems like a similar, small interpreter approach, could be used to open up the power of these BLE chips. If the chip runs a simple, well understood language, then it become easy for developers, makers, and experiments to write custom code directly on the chip itself, and build useful and interesting things. And, of course, do it for free.

Back to BASIC

I wanted to build an interpreter for these BLE chips which was easy to use and required no extra tools to use. I wanted anyone to be able to take the code, flash it onto any available CC254X chip, and start customizing. This reminded me of my earliest computer, the Sinclair ZX81 (http://en.wikipedia.org/wiki/Zx81). And this computer ran BASIC with only 1K of RAM. BASIC is an easy language to learn, and particular good for direct, on device development, where we want to reduce the "edit, compile, upload, and run" sequence into "edit and run". It's also very easy to write a compact interpreter. So BASIC is the language of choice.

Bluetooth and other Hardware

Of course, easy access to the Bluetooth stack and access to all the other hardware the CC254X chips have (e.g. digital I/O, ADCs, interrupts, timers, power management, SPI, UART, USB, etc.) is also essential. The BASIC language has been extended to make these features easy and familiar. Where possible, these addition follow the conventions popularized by the Arduino platform. So, for example, to enable pin P0(0) for input, you would use the BASIC command "PINMODE P(0) INPUT" which is similar to the Arduino syntax "pinMode(A0, INPUT)". Bluetooth keywords are model after the Services and Characteristics used in the Bluetooth LE profile and are design to make it simple to create a service, and connect it to other hardware.

A simple service might look like this:

10 ADVERT GENERAL

20 ADVERT "25FB9E91-1616-448D-B5A3-F70A64BDA73A"

30 ADVERT END

40 GATT SERVICE "25FB9E91-1616-448D-B5A3-F70A64BDA73A"

50 GATT CHARACTERISTIC "D8ABBBE7-F10B-4EC3-B781-DBCBD2334400" "On/Off"

60 GATT READ WRITE A ONWRITE GOSUB 200

70 GATT END

80 PINMODE P0(0) OUTPUT

90 GOSUB 200

100 END

200 P0(0) = A

210 RETURN

Obviously there's much to explain here, but essentially this creates and advertises a simple service with one control "On/Off" which, when written to, turns on and off a single output. On my test board this is connected to an LED.

Try it yourself

At some point I will build some hardware...

Components

1 × CC2541 Bluetooth Low Energy module HM-10 BLE module (or similar)

1 × TPS61221 Power Management ICs / Battery Management ICs

1 × NR3015T4R7M Inductors, Chokes, Coils and Magnetics / Fixed Inductors, Chokes and Coils

2 × GRM155R60J106ME4D 10uF SMT capacitor

1 × CR2032 batter holder

Project Logs

Collapse

Final
Tim Wilkinson • 10/19/2015 at 17:13 • 1 comment

Just wanted to add a final log to this project. It's been a while since I've spent any time on this. In the last 10 months I've moved away from working with the TI chips and instead are using the Nordic nRF51/2 chips. The motivation was partly because they had a more modern processor and software stack (although TI did release their new stuff) but mostly because I could use free and open tools. It's a cold day in hell when I think Eclipse is better than the alternative, but it was.
For everyone who's still interested in this work, please take it and do with it as you will. I'm happy to answer questions but because I no longer have access to the IDE, there's not much else I can do for you.
Lots of boards
Tim Wilkinson • 12/16/2014 at 22:25 • 1 comment

Shortly after I started this project someone asked if I was going to make hardware available. To be honest that was not the original goal; I was just doing this to play with bluetooth and to make it easier for others to tinker too. But then, after thinking about it for a bit, it did seem like a good idea to make cheap hardware available. After all, using Blue Basic doesn't stop you having to buy hardware to run the code, and you still need to buy the CC Debugger tool to flash the chips. But how cheap? I just finished the first prototype run of boards. Including US postage and packing, the total cost per board is $7. I think that's pretty cheap. There's no profit of course, but that's not the point of doing this. Now I just need to work out how to actually sell them.
Production
Tim Wilkinson • 11/18/2014 at 22:57 • 4 comments

I love it when a plan comes together. Here are the first two production "Petra" boards, assembled using the SMT50 pick and place machine. I have a lot more to make, but these are testing well.
App Store, OSX edition
Tim Wilkinson • 11/18/2014 at 05:39 • 0 comments

And after much mucking about with naming guidelines, the Blue Basic Console finally lands in the OSX App Store. Find it here:
https://itunes.apple.com/us/app/bluebasic/id926657840?mt=12
Lots and lots of Bluetooth
Tim Wilkinson • 11/17/2014 at 00:29 • 0 comments

Look what arrived by DHL the other day:
Hidden in the plastic wrap are 100 CC2540 modules. Now I just need to mount them on the prototype boards with the boost converter and I'll be ready to start spreading some low energy love (this would be the worst chat-up line ever).
Final prototype
Tim Wilkinson • 10/27/2014 at 21:34 • 0 comments

Here is the final prototype board, assembled and tested:
I'm finally ready to put in the big order and make a bunch of these. Excited!
AppStore Success!
Tim Wilkinson • 10/26/2014 at 17:13 • 0 comments

After a little messing about, the iOS BlueBasic console is now in the AppStore for iPhone and iPad. You can find them here:
https://itunes.apple.com/us/app/blue-basic/id926657809?mt=8
DirtyPCBs
Tim Wilkinson • 10/24/2014 at 22:18 • 0 comments

The new PCBs turned up a few moments ago. Here's the package in all its splendor.
I ordered 10 but received 18! Not bad. As you can see, this time I went with DirtyPCBs rather than OSHPark. I'm planning to do the final run of boards with them (a cost thing) so I wanted to try them out when it was a little less critical. Actually testing the boards will probably have to wait until early next week.
AppStore
Tim Wilkinson • 10/21/2014 at 05:51 • 4 comments

With the release of XCode 6.1, I can finally submit the Blue Basic console code to the AppStore. Before this people who wanted to try it out had to download the code and compile it themselves; a painful process on OSX and impossible without a developer license on iOS.
Now Apple just has to accept it ...
New modules
Tim Wilkinson • 10/15/2014 at 07:13 • 0 comments

The new modules arrived from Alibaba today. These are samples of the final ones I'll use to make my first 100 boards. They look good, but I won't really know until the Dirty PCBs turn up at the end of the week and I can assemble the next, and final, prototypes.

View all 33 project logs

Discussions

Dusan Petrovic wrote 10/29/2019 at 13:10

Hi Tim! This project is just adorable. Well done!

Are you sure? yes | no

fanoush wrote 09/18/2018 at 10:35

This is great, just found this project few weeks ago and finally I have my module flashed and basic console running :-)

I got JDY-08 module - this one is small and very cheap (<$2) on ebay/aliexpress and has external crystal (just beware to check it is really CC2541, some selllers sell Telink TLSR8266 based JDY-10 as JDY-08). I flashed it with CCloader-Rpi - I had to use hex2bin for hex firmware as flashing .bin file directly did not work. As a console I used "Serial Bluetooth Terminal" android app - one can configure custom characteristics for input/output there. So now I have READY prompt and I am ready for adventure :-) Total cost below $2. Many thanks Tim for BlueBasic, it is still relevant.

Are you sure? yes | no

John Paul Morrison wrote 09/01/2017 at 17:34

How was BlueBasic built? I don't see any makefiles and I'm not familiar with IAR.

Can this be built with SDCC? I've downloaded the BLE source from TI and seen some other projects claim to have built working code.

Are you sure? yes | no

goldkwang wrote 02/10/2017 at 05:47

HI Tim

is it possible reading timer1 value?
i want measure short pulse time using IO Polling or IO Interrupt
for example - IO interrupt
1. P0(0) interrupt occur (Rising Edge) - initialize timer1 value (0x00)
2. P0(0) interrupt condition change (Falling Edge)
3. P0(0) interrupt occur (Falling Edge) - reading timer1 value
or - reading IO Value polling
1. P0(0) input value change (Rising Edge) - initialize timer1 value (0x00)
2. P0(0) input value change (Falling Edge) - reading timer1 value

Are you sure? yes | no

Martin Vincent Bloedorn wrote 01/20/2017 at 04:14

Hello Tim,

Very nice project! I'm currently working with a customer application that (oddly enough) requires both BLE and USB MSD. For such peculiarity, I'm strongly considering beginning development with the CC2540. How was your overall experience with the chip?

Also, is there any source code for a USB MSD implementation for this device that you're aware of? Would be nice not to start from scratch :)

Thanks for the material and inspiration!

Are you sure? yes | no

Tim Wilkinson wrote 01/21/2017 at 06:19

I've not been working on any BLE stuff in a while, but I'd mostly moved to working with Nordic's various BLE chips. I much prefer their software stack and open tools. But ... I've never used USB on either - sorry.

Are you sure? yes | no

DL101 wrote 02/02/2017 at 00:33

I gave it a try at work, but I found the CC2540 to be rather complex, so I switched to the nRF52 which is way easyer to work with.

Are you sure? yes | no

kai wrote 08/02/2015 at 15:45

Hi Tim,

Awesome project, love the concept!

We're having some trouble when we compile the project ourselves (works fine with the pre-compiled hex files) and were hoping you might have suggestions.

BlueBasic appears to be working fine on our hardware (essentially a cc2541 breakout board) when using the pre-compiled hex files. When we recompile from source though, it won't even start advertising. It seems to not be getting out of its initialization. Specifically it seems to be stuck on some flashstore functions (related to reading and writing basic programs to/from flash).

Tracked through BlueBasic initialization and found that it stopped working when OSAL initialization got to the point the at the GAP bond manager was trying to pull some data from a flash store. We removed this and put it to its default and it got to the BlueBasic interpreter initialization. Once this got to the point where it initialized its own flash store it stopped working once again.

We are using the latest IAR.

Any hints?

Thanks,

Kai

Are you sure? yes | no

Tim Wilkinson wrote 08/03/2015 at 05:15

Kai,

Sorry to hear your having trouble. Nothing immediately springs to mind, and it's interesting that the hex files work but the rolled-your-own doesn't. I assume if you simply try to rebuild my hex files they are different? I'm currently using IAR 9.10.1 if that helps. I assume you've tried completely erasing the flash before writing the image (in case I'm assuming some startup condition I'm unaware of)?

Thanks

Tim

Are you sure? yes | no

kai wrote 08/06/2015 at 01:07

Thanks for the response, Tim.

Yes, tried erasing flash.

Yes, the hex files are different size. Ours is 391 and yours is 582 and you have much more data per line. We were thinking that some compiler options are different. But, all of that should be contained in the project files. So, we are stumped. We don't get any compiler warnings etc. Our hex file is at https://drive.google.com/open?id=0B9pnILOUWGCkaThxTWV2WldEeWM if you want to take a look. (That's for the 256K CC2541.)

We are using IAR 9.20 and it wants to convert the project, when we open your Github version. Looking at their change log however, it doesn't look like they changed anything of substance between versions.

Kai

Are you sure? yes | no

kai wrote 09/18/2015 at 21:02

Hi Tim,

We investigated some more. Any insight you could add would be greatly appreciated.

When debugging BlueBasic, it gets stuck in the "flashstore_findspecial()" function. This is first called from:

main() > osal_init_system() > osalInitTasks() > GAPBondMgr_Init(taskID++) > gapBondMgrReadBond() > flashstore_findspecial()

The function is trying to go through the flashstore and find a specific special ID.

The reason it never gets out of the for loop is that while searching inside the first page, ptr ends at some point before the end of that page. It starts from page = 0x9000 and ptr = 0x9004 in the flashstore. The item structure in the flash is:

// Flash item structure:

// id:2, len:1, data:len

ptr points to the ID address to see if it is the special ID. Then it moves to the next item according to the length (len). However, with high optimization compilation, ptr points to 0x9EA8 where len is 0x00. So there is zero increment index for the next loop and it is not yet at the end of the page. Hence the loop never breaks. When we tried with no optimization, ptr stuck at 0xAE48 where len is also 0x00 and less than the page_size.

The questions are:

1) what has been stored in flash(XData) before initialization?

2) If an item has length of 0x00, which is actually nothing, why does it still have a non-special ID (FLASHID_INVALID)?

3) what optimization level should be used, because optimization has an effect on the results?

Thanks,

Kai

Are you sure? yes | no

kai wrote 11/01/2015 at 22:12

SUCCESS!

Got it working. Thanks Tim, this is an awesome project!

We are going to incorporate it into our BotSpine project (see BotSpine.com). Of course, giving credit where credit is due.

As a demonstration project, we are planning to use it to build an autonomous robot that scans floors for radioactive contamination, saves the results in a file and dumps the data to a smartphone via Bluetooth. I expect at least an order of magnitude reduction in required effort, compared to traditional hardware and firmware development.

Cheers,

Kai

Are you sure? yes | no

mbresciani wrote 05/14/2015 at 00:49

Just to be clear, I am asking if you can send and receive a string or byte array via a GATT READ WRITE command..

Are you sure? yes | no

Tim Wilkinson wrote 05/14/2015 at 19:40

You can send and received array of bytes if you setup the corresponding variable as an array (using the Basic DIM command). No string support though.

Are you sure? yes | no

mbresciani wrote 05/15/2015 at 00:15

Fantastic! Thanks.

Are you sure? yes | no

mbresciani wrote 05/10/2015 at 13:29

Hi Tim,

I am turning pins on and off via the Bluetooth "On/Off" service, thanks to your example, by sending either a 1 or an 0 to an HM-10, but is it possible to send string commands rather than just one byte of data at a time?

Thanks,

Marco

For those interested, here is the Pin mapping for the HM-10 to Blue Basic commands:

HM-10 HM-10   CC254X   Blue
Pin   IO Name   IO Name   Basic
23   PIO0      P1_3   P1(3)
24   PIO1   P1_2   P1(2)
25   PIO2      P1_1   P1(1)
26      PIO3   P1_0   P1(0)
27   PIO4      P0_7   P0(7)
28   PIO5      P0_6   P0(6)
29   PIO6   P0_5   P0(5)
30   PIO7   P0_4   P0(4)
31   PIO8   P0_3   P0(3)
32   PIO9   P0_2      P0(2)
33      PIOA   P0_1   P0(1)
34   PIOB   P0_0   P0(0)

Of course, this can be found deeper in Tim's blog which I have just discovered.

Are you sure? yes | no

mbresciani wrote 04/24/2015 at 12:34

Oops, I did a list after a power up and the program is still there!

I see "AUTORUN" in the BLUE Basic command list, so I will see if I can figure out how to use it.

I tried "AUTORUN 10" thinking I can get it autorun from line 10 but after an "OK" nothing happened.

Are you sure? yes | no

Tim Wilkinson wrote 04/24/2015 at 21:09

Glad you're enjoying. Yes, the ZX-80 ... ah ... happy days.

So, the code you write is stored in Flash automatically as you've discovered. AUTORUN is either AUTORUN ON or AUTORUN OFF. It does what you might suppose, turns autorun on or off and will run your program from the beginning when you reboot/power on your board. There's a 10 second delay before this to allow you to connect (which autodisabled it).

Are you sure? yes | no

mbresciani wrote 04/24/2015 at 11:30

I have successfully uploaded Blue Basic to an HM-10 and am having a ball writing BASIC programs for it. It reminds me of the good old days with my ZX-80.

BTW is there a way to save the BASIC program yet, so that if you lost power it would auto run?

Are you sure? yes | no

lovelesh patel wrote 03/04/2015 at 03:58

I'd would love if the show the steps to convert existing cc2541 modules into programmable ones. I have a HM-10 module and I want have me custom code on it without going through the CC Debugger.

Are you sure? yes | no

rasyoung wrote 11/10/2014 at 04:24

I'd love to be able to write custom software for the Sensor-tag, good to know it loads OK and am hoping you will share you experiences here...

Are you sure? yes | no

Gary Ashton-Jones wrote 11/09/2014 at 07:34

How easy is it to add I2C pins SDA and SDL of 2541 to available pinouts? I wanted to work with a SensorTag. BB installs and runs OK. But all the cute peripherals are on I2C bus. I'm happy to do the work but don't know what the toolchain is.

Are you sure? yes | no

Tim Wilkinson wrote 11/09/2014 at 08:34

I don't know. The current I2C implementation is bitbanging (so it works on the 2540 also). Haven't had chance to look at the hardware version yet. On my list but no ETA right now.

Are you sure? yes | no

rasyoung wrote 10/03/2014 at 09:11

What a wonderful project! Would it be possible to talk to the module from Android? Say using this app: https://play.google.com/store/apps/details?id=es.pymasde.blueterm&hl=en ?

Are you sure? yes | no

Tim Wilkinson wrote 10/03/2014 at 17:52

I wish :-( The trouble is that all the serial protocols created for bluetooth are not low energy profiles. This project only deals with Bluetooth Low Energy devices, and these chips do not support the older pre-4.0 stuff. At the moment there's no equivalent standard "console" profile, so everyone makes their own, including me. A standard would be nice.

Are you sure? yes | no

rasyoung wrote 10/03/2014 at 18:44

I see, I am very early in trying to understand BLE. I do respect how quickly it pairs, and how stable the connection seems to be. Would it be inappropriate for me to ask, what the time frame for something other than Apple for a console? Or maybe would it be possible to upload your console to iTunes so I can try it on my iPod Touch 5? I'd love to give this technology a whirl!

Are you sure? yes | no

Tim Wilkinson wrote 10/03/2014 at 21:32

An iOS console program is on my list, and will probably happen soon because it wont be that different from the OSX one. I realize OSX is not exactly the platform of choice. To you personally, is Linux or Windows a preferred choice?

Are you sure? yes | no

rasyoung wrote 10/03/2014 at 22:53

Windows 8.1 is ( I can't believe I'm saying this...) growing on me. It is/has a surprisingly strong tool-chain for Bluetooth 4.0, and one click deployment to the Windows Phone, I guess they pretty much share the same code base. However, I have to imagine that Linux is a better choice for the community, and I can always run that facility as a VM on Win32. ;)

I really appreciate your effort on this project, I really don't see myself being able to navigate the manifold complexities, without your help.

Are you sure? yes | no

Ble User wrote 10/02/2014 at 11:41

Hi Tim,

I want begin by thanking you for your efforts. This is a great solution for
newbees like me to try BLE.

I flashed the BlueBasic Hex file on a HM-10 (CC2541). I ran the lowpower.bbasic
code using OSX console (objective-c version). I confirmed that the bbasic code
is getting loaded.

When I measured the current consumed by HM-10 during sleep phases it is at 5mA.
As per CC2241 data sheet in power mode 2 the current consumption should drop
down to 1uA levels. Please advice if this is expected or I am doing something
wrong.

Also please guide me to the list of bbasic commands which are supported by the
interpreter.

Are you sure? yes | no

Tim Wilkinson wrote 10/02/2014 at 16:25

I'm not sure why you're seeing the 5mA draw. When the module is initially powered it spend sometime (I forget how long ... a minute or two maybe) advertising fairly constantly, before falling back into a more limited advertising mode. So the initial power draw is definitely higher, but you should see it fall down to nearer 1-2uA eventually. You can make this happen faster by connecting then disconnecting to the device. Also, the power will be higher when connected.

There's a list of commands on the Wiki, although it's not completely up-to-date. I'm slowly writing more pages explaining more features.

Are you sure? yes | no

Ble User wrote 10/03/2014 at 05:51

You are right. I see the current draw dropping to 1uA levels. Initially I was powering the HM-10 with CC-Debugger and it was showing higher current levels. When I powered it with CR2032 the levels were as expected, down to 1uA levels.

With regards to the list of commands, do I have to issue a 'SAVE' or similar command for the cc2541 to retain the bbasic pushed wirelessly through bluebasic console. I think when I disconnect and reconnect the HM-10 power the bbasic program is getting erased.

Are you sure? yes | no

Tim Wilkinson wrote 10/03/2014 at 21:30

I really need to upgrade that command list. I try to spend Monday's on documentation so I'll take a look then. It's no longer necessary to SAVE your code. Everything is in Flash so it will persist until you wipe it out by typing NEW.

As for the CC-Debugger - yes, that'll eat lots of power when connected, even if you're not powering the board from it.

Are you sure? yes | no

Tim Wilkinson wrote 10/04/2014 at 01:31

I updated the command list https://github.com/aanon4/BlueBasic/wiki/BASIC but it might not be that helpful. Many more Wiki pages to write yet.

Are you sure? yes | no

Ble User wrote 10/16/2014 at 13:31

Hi Tim,

I am trying to parse the scanRecord HEX data received when the HM-10 beacon is scanned by an android app. I am failing to paese the string. When I compared the ScanRecord for HM-10 with the pre-installed firmware and that for HM-10 flashed with BlueBasic, I see a difference in the initial bytes. Please see below for the difference I have seen

With Original HM-10 firmware : 0201061b ff4c000215
with HM-10 flashed with BlueBasic : 02011a1a ff4c000215

I am running the ibeacon.bbasic program with few changes related to the advertising frequency. Part of the scanrecord (ff4c000215) is set through the ADVERT CUSTOM command. But the HEX string 02 01 1A 1A is getting set somewhere in the BlueBasic (not in the .bbasic file).

Are you sure? yes | no

Tim Wilkinson wrote 10/16/2014 at 21:14

Hi,

Quickly re-running ibeacon on the desktop version (easier to check the ad construction code) and it produces the HM-10 version as you'd rightly expect. Will check the CC2540 version in a moment. Which build version of BlueBasic are you using and could you post your ibeacon code (just in case some other change is interacting in a way which is perhaps corrupting memory)?

Thanks

Are you sure? yes | no

Ble User wrote 10/17/2014 at 10:34

I am using the version pointed to by the link (
https://github.com/aanon4/BlueBasic/commit/5f75cda84d903f6b0186ad4513735dfe7a8ded4f).
[https://github.com/aanon4/BlueBasic/commit/5f75cda84d903f6b0186ad4513735dfe7a8ded4f).]

I did not get the first part of your reply above, specifically "Quickly
re-running ibeacon on the desktop version (easier to check the ad construction
code) and it produces the HM-10 version". Is this something I can do? What do I
need for it.

Below is the code for parsing the scan record

public static void parseScanRecord(byte[] scanRecord)
{
for (int i = 0; i < scanRecord.length; i++)
{
int payloadLength = unsignedByteToInt(scanRecord[i]);

if ((payloadLength == 0) || (i + 1 >= scanRecord.length))
{
break;
}
if (unsignedByteToInt(scanRecord[(i + 1)]) != 255)
{
i += payloadLength;
}
else
{
if (payloadLength == 26)
{
if ((unsignedByteToInt(scanRecord[(i + 2)]) == 76) && (unsignedByteToInt(scanRecord[(i + 3)]) == 0) && (unsignedByteToInt(scanRecord[(i + 4)]) == 2) && (unsignedByteToInt(scanRecord[(i + 5)]) == 21))
{
String proximityUUID = String.format("%s-%s-%s-%s-%s", new Object[] { scanRecordAsHex.substring(18, 26), scanRecordAsHex.substring(26, 30), scanRecordAsHex.substring(30, 34), scanRecordAsHex.substring(34, 38), scanRecordAsHex.substring(38, 50) });
int major = unsignedByteToInt(scanRecord[(i + 22)]) * 256 + unsignedByteToInt(scanRecord[(i + 23)]);
int minor = unsignedByteToInt(scanRecord[(i + 24)]) * 256 + unsignedByteToInt(scanRecord[(i + 25)]);
int measuredPower = scanRecord[(i + 26)];
......
}
.......
return null;
}
.......
return null;
}
}
return null;
}

Are you sure? yes | no

Tim Wilkinson wrote 10/19/2014 at 07:26

The BlueBasic scan record you are reporting is definitely incorrect; it's just not clear how it became like that. I quickly check the code and I dont know how it constructs something like you're seeing. I tried the ibeacon code and it looks fine on my iPhone. Can you post your complete BlueBasic program (the modified ibeacon.bbasic) so I can run it here?

Are you sure? yes | no

Ble User wrote 10/19/2014 at 10:54

Following is the bbasic code I am running
================================
10 // "A Simple iBeacon service"
20 DIM M(5)
30 // "Major (0-65535)"
40 M(0) = 0
41 M(1) = 2
50 // "Minor (0-65535)"
60 M(2) = 0
61 M(3) = 4
70 // "Power"
80 M(4) = 0xC8
90 ADVERT GENERAL
100 ADVERT CUSTOM "FF 4C 00 02 15" "B9 40 7F 30 F5 F8 46 6E AF F9 25 55 6B 57 FE 6D" M "00"
110 ADVERT END
120 // SET A NAME IN THE SCAN RESPONSE
130 SCAN NAME "iBeaconT1"
140 SCAN END
150 CONFIG POWER, 2
160 // "3200 = Advertise every 2 seconds"
170 T = 1600
180 BTSET LIM_DISC_ADV_INT_MIN, T
190 BTSET LIM_DISC_ADV_INT_MAX, T
200 BTSET GEN_DISC_ADV_INT_MIN, T
210 BTSET GEN_DISC_ADV_INT_MAX, T
SAVE
AUTORUN ON
================================

Are you sure? yes | no

Tim Wilkinson wrote 10/20/2014 at 01:45

Could you try this with the current firmware? A couple of things if you do - 1) BTSET is now BTPOKE, and 2) you don't need to SAVE anymore.

I'm running your code on a custom CC2541 board and I can see the beacon correctly being advertised. I dont have any easy way to dump the raw packets, but the Mac's decoded version is also correct.

Not sure what else to suggest if new firmware isn't helping.

Are you sure? yes | no

Ble User wrote 10/29/2014 at 03:57

Tried with the latest firmware (Oct 27th). It worked for me.
Is there a way I can set the Tx-Power to value lower than -23db?
Also I noticed, there is little extra time taken in putting the beacon to sleep after the Tx Rx peaks, as compared to HM-10 original firmware does. Could it be because of some of the bbasic instructions I have in my program?

Are you sure? yes | no

Tim Wilkinson wrote 10/29/2014 at 05:32

TI's bluetooth API only allow very specific power settings, and -23dbm is as low as it goes. As for the sleep time, are you referring to the time it takes the device to stop broadcasting like a manic thing to going intermediate? I hadn't though to allow tinkering with that.

Are you sure? yes | no

Ble User wrote 10/29/2014 at 15:21

It's time taken to put the device to sleep.

Are you sure? yes | no

deandob wrote 09/22/2014 at 09:58

I posted the below in the latest update post but I guess the main comments section is more appropriate.

I'm interested, after spending almost a day trying to work out how to program the 8051 on the CC2540 chip and giving up due to the awful (for hobbyist) toolchain - TI have definitely done themselves a disservice making it hard to adopt their BLE platform, especially as the hardware is cheap and accessible (eg. HM-10).
You obviously see the potential of these chips and the need to make it easy to work with them - in fact a brilliant idea to add an interpreter as most use of the 8051 will be for simple computations and sensor interfacing.

My use case is simple - I want to add a temperature sensor on a button cell that lasts several years and reads the temperature every 5 - 10 mins and when changed then send it to the host over BLE. Will likely use a low voltage sensor like the TMP35 which is good for down to 2v with still a linear response and won't need a buck converter and is low power.

Looking at your code and write up on github I'm still missing a few things:
1) Will the interpreter feature a sleep function that uses the sleep timer in power mode 2 to wake up the device (24 bit timer means almost 10 minutes of deep sleep is possible)?
2) without having to buy the TI cc debugger - for a HM-10 there is a firmware update feature over serial available that should be able work to avoid buying the $60 cc debugger for a 1 off project (a TTL / RS232 converter still needed). I assume you haven't tested this with your HM-10 mule?
3) The code console is in OSX - only 5% of the world's computers support that (I don't have any Macs). For the rest of us, is there any other option to upload the basic code?

Do keep posting updates and thank you for sharing

Are you sure? yes | no

Tim Wilkinson wrote 09/22/2014 at 17:17

Hi,

Let me take a stab at answering your questions. More than happy to help if I can:

1. BlueBasic will drop into power mode 2 whenever it's got nothing better to do. If you want to read the temperature periodically the simplest thing to use is a Basic TIMER. I will write that up on the Wiki this morning so you can see the syntax. There is also a DELAY command which operates much like the Arduino one. When in a DELAY (or doing nothing waiting for a TIMER) the device will drop into power mode 2.

2. Interesting idea using the HM-10 firmware updater to get BB onto the device rather than the CC Debugger. Without knowing a lot more about what they need it would be tricky to do. The current BB HEX files consume the entire 256K of flash because the contains both BB and the over-the-air firmware uploader. That said, assuming the BIN files for the HM-10 are standard, I'd just need to know where the binary is suppose to land once on the device (to tweak the relevant linker config). It's not in my plans currently, but I'd happily accept a configuration into master if you or someone else works it out.

3. Yeah, I have a Mac so it's what I wrote. There are plans to write a Windows version of the console program (which would be much more useful) as well as an iOS and Android one. My C# is pretty rusty.

Hope some of this helps.

Are you sure? yes | no

deandob wrote 09/22/2014 at 21:06

Hi Tim, thanks for the response.

Good to know that when ordering a cc2540/1 device to ensure it is the model with the 256K flash (I don't recall seeing that in your write-ups - probably worth highlighting).

Regarding timer - I read your wiki updates, it seems that the timer function only uses timers 0 - 3 and does not use the sleep timer. The chip consumes a lot less power when sleeping if the sleep timer is used (runs on 32Khz clock), is it possible to add the sleep timer to the interpreter? Its a make or break feature for battery life.

I'll need to look into the flashing options further, there is also an alternative to purchase a cc debugger clone on aliexpress for a lot less.

Regarding your console, with only a mac version there isn't going to be a lot of interest in others adopting your solution, at least initially (if open source adoption is your goal). I may be able to help as I know c# (vb.net is my language of choice on .net), javascript and node.js. Node.js to access the serial port using an Express web server to host a HTML5/javascript UI would be the most open and also mean you wouldn't need to have Mac/PC/.NET/IoS/Andriod versions of your console. Another option may be to run an OSX virtual machine on a PC. I had a quick look at your Objective-C on github and it doesn't look like it will be an easy port - perhaps if you can explain exactly what you are doing or if there is a simpler way to get the Basic code across to the chip without necessarily having the fancy UI (eg. use the file system to transfer a file across, or a serial transfer which is what I assume your console does) as a start.

Are you sure? yes | no

Hugh Darrow wrote 09/04/2014 at 04:05

I love it man, keep up the great work, great attitude, and great goal.

Are you sure? yes | no

Tim Wilkinson wrote 09/03/2014 at 21:42

I did yes. I have a few of their modules kicking about the workshop. There's a lot to like with them. But for me this project is all about creating open software and hardware. The goal is to have an easy to use, license free, software stack for people to experiment with, a set of examples and tutorials, and a few of hardware designs people can easily build. I might even go so far as putting up some protoboard on Tinder (at cost) to make it really easy to play with.

Are you sure? yes | no

Bob Baddeley wrote 09/03/2014 at 13:04

Have you looked at the BLE112/BLE113 by BlueGiga? They have modules that allow you to program in their own BGScript, which is sort of a combination of C and Javascript. There's no need for IAR, the modules are FCC certified, they have a plugin for Notepad++ so the development environment is free, and they have lots of sample applications to show how to interact with the UART, SPI, ADC, I2C, etc.

Are you sure? yes | no

BlueBasic: BASIC for Bluetooth

Description

Details

Components

Project Logs

Collapse

Final

Lots of boards

Production

App Store, OSX edition

Lots and lots of Bluetooth

Final prototype

AppStore Success!

DirtyPCBs

AppStore

New modules

Discussions

Similar Projects

Another installment in the series 'Me building...'

Pocket-Sized Imsai-Style Z80 Board

Searching for a better Pro Mini

The nRF9160 Feather

BlueBasic: BASIC for Bluetooth

Become a Hackaday.io member

Just one more thing

Description

Details

Components

Project Logs Collapse

Enjoy this project?

Discussions

Become a Hackaday.io Member

Similar Projects

Does this project spark your interest?

Report project as inappropriate

Send message

Remove Member

Project Logs

Collapse