http://forum.pololu.com/atom.php?f=302010-03-05T00:00:00ZWixel - Pololu robotics forumSupport and community forum for the Wixel Programmable USB Wireless Module.Re: internal pull-down resistors not workingDavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152015-02-26T16:12:23-08:002015-02-26T16:12:23-08:00http://forum.pololu.com/viewtopic.php?p=43412#p43412Forum: WixelThank you for the information. Unfortunately, it sounds like something is weakly pulling up P1_3, but it is strong enough to override the pull-down resistor.

--David]]>
Re: internal pull-down resistors not workingmc1603http://forum.pololu.com/memberlist.php?mode=viewprofile&u=108792015-02-26T14:59:48-08:002015-02-26T14:59:48-08:00http://forum.pololu.com/viewtopic.php?p=43407#p43407Forum: WixelI checked and P1_3 is not shorted to VALT. The voltage measures 2.15V.

After connecting to ground through a resistor, it works and outputs "0". The voltage measures 385mV.

The Wixel worked just fine before this. I didn't notice any problems (but I also wasn't using P1_3). The previous application was to use the Wixel to add radio functionality to an Arduino.

Thanks for your help.]]>
Re: internal pull-down resistors not workingDavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152015-02-25T13:41:57-08:002015-02-25T13:41:57-08:00http://forum.pololu.com/viewtopic.php?p=43391#p43391Forum: WixelIt does sound like something is wrong with Wixel #1. It could be that the P1_3 pull-down resistor is broken, or that something else is pulling the line high, or the digital input does not work. Maybe P1_3 is shorted to VALT, a 5V node that runs near it. If you measure the voltage on P1_3 with a multimeter, what reading do you get? If you connect P1_3 to GND through an appropriate resistor (220 Ohms to 1000 Ohms), does the reading of P1_3 from the test script change from 1 to 0, and does that affect the voltage on the line? Was the Wixel generally working for you before you noticed this problem? What have you used it for, and was P1_3 connected to anything?

Regarding the UART1 TX line, it is common for microcontroller peripherals to override the configuration of an I/O pin while they are enabled, by design. Your results indicate that this is true for the CC2511's UART, but if you want more confirmation then it is probably documented somewhere in the CC2511 datasheet.

--David]]>
Re: internal pull-down resistors not workingmc1603http://forum.pololu.com/memberlist.php?mode=viewprofile&u=108792015-02-25T11:39:52-08:002015-02-25T11:39:52-08:00http://forum.pololu.com/viewtopic.php?p=43388#p43388Forum: WixelHi David. Thanks for providing that test script. Here are the results with my two Wixels.

Wixel #1My code outputs: 0 1 0 0 1 0Your code outputs: 0 1 0 0 0 0

Wixel #2My code outputs: 0 0 0 0 1 0Your code outputs: 0 0 0 0 0 0

I figure there are two things going on.(1) Wixel #1 has a pull down resistor on P1_3 that doesn't work.(2) My program is doing something to P1_6. I tracked this down and it turns out I forgot to remove some code that was initializing UART 1 (P1_6 is the TX for UART 1). But, the call to uart1Init happens before the calls to setDigitalInput and setPort1PullType. So, shouldn't it get overridden?]]>
Re: pointing to a structDavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152015-02-24T10:49:07-08:002015-02-24T10:49:07-08:00http://forum.pololu.com/viewtopic.php?p=43376#p43376Forum: WixelThat is probably true. If you want to be sure, you can make a simple program that defines a struct like that and then prints sizeof(mystruct) to the USB virtual COM port.

I compiled it using commit e837d08 of the Wixel SDK (the latest commit on github right now) and SDCC 3.4.0 for Windows. It outputs "0 0 0 0 0 0" when nothing is connected to the I/O lines, but I can make any of those numbers go to 1 by connecting an I/O pin to 3V3. I also used a multimeter to measure the current that flows into each pull-down resistor when it is connected to 3V3, and I got about 150 uA, as expected.

To rule out any potential issues with your compiler or code, I have attached the compiled WXL file that was generated from the code above:

test.wxl

Could you try running that file on your Wixel and see if you get the same results? You can write it to the Wixel by running:

wixelcmd write test.wxl

--David]]>
Re: pointing to a structtapisgehttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=149732015-02-23T23:10:33-08:002015-02-23T23:10:33-08:00http://forum.pololu.com/viewtopic.php?p=43371#p43371Forum: WixelFor the same reason, is it correct to imagine that if I built BIT myData[120] it would take 120 bytes?]]>
internal pull-down resistors not workingmc1603http://forum.pololu.com/memberlist.php?mode=viewprofile&u=108792015-02-23T17:40:23-08:002015-02-23T17:40:23-08:00http://forum.pololu.com/viewtopic.php?p=43368#p43368Forum: WixelAnyone else having problems with the internal pull-down resistors not working?

Needless to say, the Wixel's GPIOs are not connected to anything. I'm getting "0 1 0 0 1 0". What's weird is that when I try another Wixel I get "0 0 0 0 1 0". Should I take this to mean that the pull-down resistors are broken? I should note that when I change the code to enable pull-up resistors (setPort1PullType(1)) all inputs are high.]]>
Re: pointing to a structDavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152015-02-23T14:06:46-08:002015-02-23T14:06:46-08:00http://forum.pololu.com/viewtopic.php?p=43359#p43359Forum: WixelYou should be able to pack your 120 bits of data into 15 bytes, but you will have to do it a different way. Every struct (including a uint10) must occupy a whole number of bytes, and cannot start in the middle of a byte. One reason for that is that the C compiler needs to be able to produce pointers to such structs, and pointers are not designed to point at individual bits inside a byte. So when you write uint10 sample[12], that array actually takes 24 bytes.

I am not sure if it would work to just have 12 bit fields with 12 different names inside your radioPacket struct.

--David]]>
Re: pointing to a structtapisgehttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=149732015-02-23T13:52:10-08:002015-02-23T13:52:10-08:00http://forum.pololu.com/viewtopic.php?p=43358#p43358Forum: WixelThe reason why I use 10-bit values is to optimize transmission: In an area of 120 bit I would like to store 12 10-bit samples instead of 7 uint16 samples.

Maybe I will try different ways to solve my problem. I might enlarge the buffer size in my radio library; otherwise I might try to populate the buffer with a shifting procedure that allows me to optimize space usage without using structs. The second way is more difficult to implement but smarter, since I would not modify the radio library.]]>
Re: pointing to a structDavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152015-02-23T11:01:15-08:002015-02-23T11:01:15-08:00http://forum.pololu.com/viewtopic.php?p=43353#p43353Forum: WixelI do not see anything in the code you posted that would cause that behavior.

I did notice that your loop that prints the values doesn't look quite right:

for (i = 0; i < rxPacket->length - 8; i++) {

If the rxPacket->length is a number of bytes, then a packet holding 12 samples would actually have a length of 32, which means your loop would print out 24 different values. The example output you showed only had 12 values though, and I am not sure why.

I suspect that sizeof(typeConverter) will actually be 3, but it looks like you were trying to make it be 2 because of the way you added 6 bits of padding.

Since the data at the beginning of the packet is fine and the data at the end of the packet is corrupted, I would look for issues where you might specify the length of the packet incorrectly when sending it, or maybe the length you are specifying is too long for the underlying radio library to handle. You should make sure you know what sizeof(radioPacket) is; I think it is 33 because each uint10 struct will take 2 bytes.

I suggest that you simplify your code as much as possible, and post the full source code of both apps here if you are still having issues. Also, you might try just using uint16 integers to hold your data instead of trying to use bit fields.

--David]]>
Re: pointing to a structtapisgehttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=149732015-02-23T00:01:01-08:002015-02-23T00:01:01-08:00http://forum.pololu.com/viewtopic.php?p=43348#p43348Forum: WixelExample: at every radio packet I send a queue of 12 10-bit values. I modified the code in order to send a constant arbitrary value (823, 0b1100110111) instead of sending samples from adc.

I cannot explain myself why constant zeros and why decreasing values for every received packet, and why I obtain also variable values... ]]>
Re: pointing to a structtapisgehttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=149732015-02-22T23:12:01-08:002015-02-22T23:12:01-08:00http://forum.pololu.com/viewtopic.php?p=43347#p43347Forum: WixelThank you, David.I've another question that is related with 10-bit structs as above, but also with the way the bits are transmitted by radio module of CC2511.

When print my data, it seems bits are in a different order with respect to the transmitted ones.]]>
Re: is Wixel compatible with generic CC2500wondererhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=155822015-02-20T19:01:25-08:002015-02-20T19:01:25-08:00http://forum.pololu.com/viewtopic.php?p=43332#p43332Forum: WixelThanks, appreciate the fast response.

I agree about the antenna being a tricky addition, RF is not my specialty it's why I'm searching for a tested module in the first place.The reason I asked is because on the SparkFun site someone mentioned a "U.FL to SMA cable" to connect the Wixel to an antenna but I'm not convinced it's that simple.

Btw, nice products and nice site, found Polulu thanks to SparkFun reviews :)]]>
Re: is Wixel compatible with generic CC2500nathanbhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=137002015-02-18T14:34:28-08:002015-02-18T14:34:28-08:00http://forum.pololu.com/viewtopic.php?p=43283#p43283Forum: WixelYes, we expect that the Wixel can be used to send data to any CC2500 client. There should not be anything about the Wixel that limits the radio settings available for the CC2511. The USB bootloader does not touch the radio, and there are no hard-burned-in fuse settings or anything like that affecting it.

We have had others suggest adding an external antenna, and it is something we are interested in, but it is not something we are likely to have any time soon. It might be possible to modify one of our current Wixel boards to add an external antenna, but working with RF signals can be tricky and I suspect it would be difficult to do. We have not heard of anyone who has been successful doing this.]]>
is Wixel compatible with generic CC2500wondererhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=155822015-02-17T16:35:55-08:002015-02-17T16:35:55-08:00http://forum.pololu.com/viewtopic.php?p=43258#p43258Forum: Wixelsearching for a good/reliable TI CC2500 compatible RF transmitter. Can the Wixel be used to send data to *any* CC2500 client?

I know the CC2511 chip can do CC2500 communication but I’m not sure if the "Wixel" has been programmed with it’s own protocol so that it is not compatible with a generic CC2500.

If the answer is yes, can the Wixel be outfitted with an external antenna to increase range?

I can't make changes to the CC2500 client aside from what the sender can negotiate.I have some documentation on the CC2500 settings and protocol, I will need to be able to send the expected protocol the client expects.

Hello. The -> operator takes care of dereferencing the pointer, so the expression (ptrData + i)->value10bits is not a pointer and it is inappropriate to try to dereference it again using the asterisk. I think you can fix this by just removing the asterisk.

--David]]>
pointing to a structtapisgehttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=149732015-02-13T14:24:14-08:002015-02-13T14:24:14-08:00http://forum.pololu.com/viewtopic.php?p=43202#p43202Forum: WixelHello,maybe this could be a topic more general than Wixel, but since I'm using that board, I post here. I apologise if administrators will have to move my post in a more appropriate section of the forum.

I want to optimize a radio packet for transmission; in order to store in it the largest amout of data, I defined a new type and a struct like this:

the uint10 type allows me to store an adc reading (@ 10-bit resolution) and the union typeConverter allows me to manage it in a smart way.

The problem arises when I try to store those readings into a buffer obtained by txBuf = radioNetworkTxCurrentPacket() (radio_network is an advanced radio protocol that allows Wixels to create a mesh network; it work like radio_queue library).

Thank you!]]>
Re: best accuracy of wixel adcPeterPanhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=97412015-01-30T15:12:15-08:002015-01-30T15:12:15-08:00http://forum.pololu.com/viewtopic.php?p=42991#p42991Forum: WixelGood point. maybe I'll check on the Ti forums about this too. Perhaps there are recommended resistance values when you need to measure through a voltage divider. On that note, I do know I'm currently doubling the error, because I'm using a 1/2 voltage divider to measure a battery that can never be more than 4.2V. Instead of two 10K resistors, perhaps I'll try a combination that gives me a 3/4 ratio, so that 4.2 will = 3.15 instead of 2.1. Right there that should cut the error % some.

I'm having a tough time gauging how critical this is. It is possible to over-think this stuff too. Its purpose is to warn a user when there are only a few hours left of life in the cell, to alert him/her to re-charge as soon as convenient. If you've ever looked at the discharge curve of a LiPO cell, Its pretty flat up to a a certain point, and after that its as as steep as a cliff. Thats why simply waiting for adcReadVddMillivolt() to drop didn't work out for me. By the time that voltage started dipping by 100mV, the warning would only be good for about 10 minutes at best, before shutdown was mandatory (I have a separate precision voltage monitor circuit to force that). I've done my own discharge study of the cell I'm using, based on the actual drain of the wixel running the app I've written. From that i can see that the more accurately I can measure cell voltage when its between 3.8 and 3.7 volts, the better chance I have of allowing maximum hours use before the warning starts, while still allowing a couple of hours "grace" after the warning. Its not an exact science (there's battery age, temperature, etc.). But reliably measuring within 50mV of the truth would ease my mind.

Since the cell is charged by a special management chip that stops exactly at 4.2, perhaps I can write a routine to let the user cause a self calibration the first time its turned on after a charge. Or I suppose I could calibrate each one individually with a saved variable or param_variable.]]>
Re: Wixel and MatlabDavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152015-01-27T13:20:47-08:002015-01-27T13:20:47-08:00http://forum.pololu.com/viewtopic.php?p=42935#p42935Forum: WixelHello.

I am sorry you are having trouble with the Wixel on Mac OS X. We do not know of any problems with the Mac OS X driver (which is named AppleUSBCDCACM), and that driver is used by other popular devices besides the Wixel. If you would like help troubleshooting, please let me know the details of what you are doing and what problems you are seeing.

--David]]>
Re: best accuracy of wixel adcDavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152015-01-27T13:12:18-08:002015-01-27T13:12:18-08:00http://forum.pololu.com/viewtopic.php?p=42934#p42934Forum: WixelDepending on which part of the procedure causes the error, you could make new versions of adcReadVddMillivolts and/or adcConvertToMillivolts to reduce the error. To say whether this is a good idea or not depends on your application. If you want your code to work reliably on thousands of different units and across a wide range of temperatures, then keep in mind that the results you are seeing today with these three Wixels are not necessarily representative. By adding correction offsets to the code you might actually make the errors be worse under other conditions. I think it would be better to come up with an upper bound of how large the error could be based on the information in the datasheet, and then whenever you are using the ADC to make any kind of important decision, you would account for the possibility of that much error.

--David]]>
Re: best accuracy of wixel adcPeterPanhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=97412015-01-27T08:50:03-08:002015-01-27T08:50:03-08:00http://forum.pololu.com/viewtopic.php?p=42929#p42929Forum: WixelStill, if indeed I'm finding the error to be consistent enough to correct, the place to do it would be to replace adcReadVddMillivolts() with my own, in which a corrected multiplier and/or zero offset was supplied, correct?]]>
Re: Wixel and Matlabmons91http://forum.pololu.com/memberlist.php?mode=viewprofile&u=152632015-01-27T00:13:20-08:002015-01-27T00:13:20-08:00http://forum.pololu.com/viewtopic.php?p=42925#p42925Forum: WixelMoreover the same code tested on Windows with Matlab works perfectly! Do you know if there are some issues with the Mac Os X Driver?]]>
Re: best accuracy of wixel adcDavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152015-01-26T16:15:07-08:002015-01-26T16:15:07-08:00http://forum.pololu.com/viewtopic.php?p=42916#p42916Forum: WixelHello.

We have not done any experiments to characterize the ADC on the CC2511F32, so all the information we have about its accuracy can be found in the datasheet. Errors from both the ADC and the internal voltage reference used by adcReadVccMillivolts could contribute to the error you are seeing.

--David]]>
Wixel and Matlabmons91http://forum.pololu.com/memberlist.php?mode=viewprofile&u=152632015-01-26T13:50:30-08:002015-01-26T13:50:30-08:00http://forum.pololu.com/viewtopic.php?p=42903#p42903Forum: WixelHi all!!I'm trying to build an application that collect some data from the wixel, since I've to perform some data operations I'm trying to read the data from Matlab but actually the wixel shows a strange behaviour...sometimes it works, sometimes it doesn't...I built a similar application with C# some time ago on windows, now I'm on OS X but I can't figure out why it has this alternate behaviour...do you have some suggestions about?

Thx]]>
best accuracy of wixel adcPeterPanhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=97412015-01-25T16:22:41-08:002015-01-25T16:22:41-08:00http://forum.pololu.com/viewtopic.php?p=42894#p42894Forum: WixelAssuming I am correctly calling adcSetMillivoltCalibration(adcReadVddMillivolts()) occasionally, and converting raw voltage readings on a P0 port using adcConvertToMillivolts(adcRead(MY_ADC_CHANNEL)), what is the best accuracy I should hope for. I don't want to make a long post unless you need it to verify my code, but after testing with 3 wixels I'm finding them all to be between 40-80 mV high when reading a known 3.00 V source, verified with two separate fluke DMMs. This is not horrible, only around 2% off. But as i said they all seem consistently high. Is that about correct, or do my findings seem suspicious?]]>
Re: curious about current draw experiencesPeterPanhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=97412015-01-23T19:05:00-08:002015-01-23T19:05:00-08:00http://forum.pololu.com/viewtopic.php?p=42881#p42881Forum: WixelHmmm... well I'm not using any serial port emulation. My transmissions are short (perhaps 22 bytes plus overhead) binary structures, mostly based on the low level example in your "test_radio_signal" example. So its hard to say what the equivalent low level RF modulation equivalent of a baud rate would be. Its basically as fast as the packet can be sent.

As far as transmission rate over time time, if the app has not detected changes in the data I'm sending, i just send one packet about every 1/2 second. There is no "turn around" to receive an acknowledge, its almost more like UDP data gram scheme... just keep sending with some repeats to add reliability, and the usual message ID to the receiver can tell whats new and what's just repeats. But, if data changes are detected in my application, I'll send out as many as 10 such packets perhaps 10mS apart, plus whatever recovery overhead the radio calls require. And even when I force continual changes, it barely adds a milliamp or so avearage. Still a long way from the near 30mA in the docs.

Don't get me wrong... I'm not complaining! The app will run over 18 hours on a little 200mAh LiPO cell, before my battery protection circuit kicks in to shut things down. But I just thought maybe some improvements were made in the MCU itself since the first Wixel inception.]]>
Re: curious about current draw experiencesJeremyThttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=102522015-01-23T15:04:06-08:002015-01-23T15:04:06-08:00http://forum.pololu.com/viewtopic.php?p=42870#p42870Forum: WixelHello.

The CC2511 datasheet shows higher current draws when the radio is transmitting data. I suspect your low current draw is due to the rate you are transmitting at. How often are you sending data? What baud rate are you using?

- Jeremy]]>
Re: possible to detect a low supply voltage condition?DavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152015-01-23T11:09:29-08:002015-01-23T11:09:29-08:00http://forum.pololu.com/viewtopic.php?p=42869#p42869Forum: WixelHello. The P2_* pins on the Wixel cannot be used for ADC readings.

--David]]>
Re: possible to detect a low supply voltage condition?PeterPanhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=97412015-01-23T09:46:07-08:002015-01-23T09:46:07-08:00http://forum.pololu.com/viewtopic.php?p=42867#p42867Forum: WixelWell here I go again, resurrecting an old thread. My app is running on a little 200mAH LiPO cell, and I needed to warn the user when the cell was getting low. A LiPO cell charges to a max of about 4.2V, and can safely operated down to about 3.0 to avoid degrading the cell. So I was using adcReadVddMillivolts() to warn the user. It took a little experimentation to compensate for the shottky diodes, but it seemed to work.

Unfortunately the discharge curve of a LiPO cell is such that by the time it starts effecting the adcReadVddMillivolts() reading, you really don't have much time left. It would be much better if I set up an A/D pin with a 1/2 voltage divider, to just read the VIN voltage directly. That way I can warn the user when the cell is at about 3.4V, half of which would be 1.7V ( well below the 3.3V reference).

Before I do this, I note that the Wixel already has a 100K resistor between VIN and P2-3, and I believe the wixel docs hint that the P2 pins might be internally pulled low. I don't think the P2 pins can be used for A/D readings, but if I'm wrong please tell me, because it will make my task easier. I can just as easily re-do the math for a 100K resistor in series with the internal 20K pull down.]]>
curious about current draw experiencesPeterPanhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=97412015-01-23T08:29:59-08:002015-01-23T08:29:59-08:00http://forum.pololu.com/viewtopic.php?p=42866#p42866Forum: WixelMy wixel app is being powered by a single LiPO cell, which will present anywhere from about 4.2 V down to 3.4V during its useful life. This particular app only transmits, but does so quite frequently, with transmission events occurring based on sensed changes. Anyway, I have used well over 2 dozen wixels and have never seen one draw more than about 8MA, confirmed both by direct measurement as well as the battery longevity. The docs say significantly hight current should be expected. So has the wixel circuit or MCU itself been improved since the original doc files were written, or am I just lucky? I certainly am using a lot of features, including A/D readings which I understand to add to current draw. I've also used the USB for diagnostic output, with the +5 line open. Still barely more than 8mA.]]>
Re: Buffering for USB transmissiontapisgehttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=149732015-01-14T10:16:25-08:002015-01-14T10:16:25-08:00http://forum.pololu.com/viewtopic.php?p=42727#p42727Forum: WixelIn effect I was starting exactly from test_adc app. I'm trying to get in confidence with all of the apps in SDKThanks a lot, David.Tapisge

DavidEGrayson wrote:Hello, Tapisge.

It looks like you are calling printf in lots of places. You should be careful about when you call it or else you will cause a buffer overflow in putchar. It looks like your code is based on our test_adc app, which avoids buffer overflows by only calling putchar/printf to generate a new report after the report buffer is empty. The "reportLength == 0" condition in sendReportIfNeeded takes care of that.

Also, I see you are constantly setting reportBytesSent to zero. That will interfere with the code that is using that variable and probably make it impossible to send reports longer than 128 bytes.

I did not look carefully at all of your code so there could be other problems too.

It looks like you are calling printf in lots of places. You should be careful about when you call it or else you will cause a buffer overflow in putchar. It looks like your code is based on our test_adc app, which avoids buffer overflows by only calling putchar/printf to generate a new report after the report buffer is empty. The "reportLength == 0" condition in sendReportIfNeeded takes care of that.

Also, I see you are constantly setting reportBytesSent to zero. That will interfere with the code that is using that variable and probably make it impossible to send reports longer than 128 bytes.

I did not look carefully at all of your code so there could be other problems too.

--David]]>
Buffering for USB transmissiontapisgehttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=149732015-01-14T07:25:19-08:002015-01-14T07:25:19-08:00http://forum.pololu.com/viewtopic.php?p=42725#p42725Forum: WixelHello to everyone. I encountered some problems in buffering data for usb serial transmission, and I would like to know if it is problem that is related to variable dimensioning or... what else?

I give you a little example. In the code you'll find below, I am trying to implement a small circular buffer. (My long-term goal will be to use it for sampling a signal and later encode it and transmit it). As you can see, MAX_ITEMS is defined as 10. If I try to define a bigger value, or even if I try to uncomment the printf instructions in the main loop, transmission crashes after few loops. I would like to know if it is a problem related to USB buffering or other things that I, like a newbie, cannot understand.

]]>
Re: 8 khz samplingtapisgehttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=149732015-01-07T00:04:34-08:002015-01-07T00:04:34-08:00http://forum.pololu.com/viewtopic.php?p=42642#p42642Forum: WixelOh... Sorry! You are in right, there was a problem with the probe cable. Thank you for your suggestion!Tapisge

DavidEGrayson wrote:I tried your code here and it works as expected. I suspect there is an issue with either the triggering or the horizontal scale on your oscilloscope.

--David

]]>
Re: 8 khz samplingDavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152015-01-06T14:44:46-08:002015-01-06T14:44:46-08:00http://forum.pololu.com/viewtopic.php?p=42632#p42632Forum: WixelI tried your code here and it works as expected. I suspect there is an issue with either the triggering or the horizontal scale on your oscilloscope.

I'm trying to adopt interrupt, but maybe I fail something.I wrote a simple application that, theoretically, swaps the status of the pin P1_7 every 1 ms.I simply replicated on timer T3 same data of timer T4 in order to obtain an interrupt at every millisecond. The interrupt service subroutine simply switches the status of the pin P1_7.With an oscilloscope, I should see the square wave, but I observe two continuous orizontal lines, as if the pin were changing level too much fast. I post my code...

The Wixel SDK does not provide any functions to help you schedule tasks that need to happen more than once per millisecond. However, you could look at time.c in the Wixel SDK to see how the timekeeping is implemented there. Timer 4 counts up and overflows from 187 to 0 approximately every millisecond. In your application, you could consider either reading the value of T4CNT or setting up a different timer and using that to schedule your ADC readings.

That was exactly what I was missing - it wasn't particularly clear from the datasheet but I should have guessed both WORIRQ (Event0) and IEN0 (Sleep Timer) would need to be enabled. I've got a test application up and running and have integrated it into the Pololu libraries. All seems to be working well but I'm not sure if I'm doing a bit too much in terms of saving, disabling and then restoring interrupts when going into PM2 and whether that's something the 'user' should be doing if they need it. I've left everything enabled for PM1 and PM3 - with PM3 requiring an external interrupt to wake up as the sleep timer is not supported in that mode. The USB device will disappear in PM2 and PM3 but the datasheet seems to suggest it could suspend and still be visible in PM1 but I haven't been able to achieve that yet.

Anyway it's all on my fork of wixel-sdk found here if anyone is interested: https://github.com/lummo/wixel-sdkThe code is more or less an implementation of Design Note DN106 with all the pieces put together - I've kept in the TI comments and added my own where appropriate. The strange parts with the DMA controller are recommended to work around a bug detailed in errata note SWRZ014: http://focus.ti.com/lit/er/swrz014c/swrz014c.pdf.

I enabled a pull-down on P2_4 and drove P2_0 high in the code below, but there might be other ways to take care of them.]]>
Re: Writing to flash programaticallyKittihttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=150002015-01-04T01:38:25-08:002015-01-04T01:38:25-08:00http://forum.pololu.com/viewtopic.php?p=42598#p42598Forum: Wixel

PeterPan wrote:Hey David,

I just want to thank you again for this insight and example from your bootloader, and to encourage you once again to consider packaging up this feature into a library routine. Granted, it requires a bit of careful planning to create a "user interface" out of the buttons I have on my project, use them to fill in a configuration structure, save the data to the MCUs flash, and then retrieve it the next time the application runs. But even to just save some program state information, which you could then "resume" on a future run: Do you realize what a game changer it is? For any MCU application to be runtime "field programmable", or retain program states without the user having to to reload code (and stuff a bunch of param_variables) is an amazing advantage. Maybe I'm exaggerating, but to me this is simply huge!

For me, not only can my transmitter application now retain a boat load of custom configuration, but with a little planning a command can be set to multiple receiver apps, which will then also be able save customizations in flash. Just the security advantage alone is noteworthy! I can now field configure a unique pattern on the header of a communication packet, and send a special command to all receivers to save and record itit. From that day forward, these receiver apps are secure, and can never be hijacked by anyone running a clone of my application, even if i make the app public domain. That may be unlikely, but security is a major issue these days, and its only one of thousands of possibilities this opens up.

Anyway, that's just my 2¢ . I'm sure I'll use it in all my current and future apps, whether in the wixel, or via my own implementation imbedding a CC2511F32 eventually. But I guarantee that a library feature to pragmatically write to a reserved block of flash, and then retrieve that on subsequent runs. will make a lot of lights turn on in a lot of your customer's minds. please think about standardizing it!

If you set FADDR to point to topmost 1 KB of the application flash space that should be good because the SDCC compiler likes to puts its data at the bottom]]>
Re: Wixel Mesh Network?Kittihttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=150002015-01-04T01:37:25-08:002015-01-04T01:37:25-08:00http://forum.pololu.com/viewtopic.php?p=42597#p42597Forum: Wixel

Mif wrote:Hello all,This is a great thread! there is a lot of useful information here, but it seems like it died long time ago.

Have anyone finally figured out how to create a real Mesh network with the Wixels?

Thanks!

While it reaches into the next room no problem, it will not cover the whole house.]]>
Re: Writing to flash programaticallyKittihttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=150002015-01-04T01:33:23-08:002015-01-04T01:33:23-08:00http://forum.pololu.com/viewtopic.php?p=42596#p42596Forum: WixelAs cumbersome as it seems, at least it can be done in a "field" situation!]]>
8 khz samplingtapisgehttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=149732015-01-03T02:09:17-08:002015-01-03T02:09:17-08:00http://forum.pololu.com/viewtopic.php?p=42590#p42590Forum: WixelHello to everyone.

I'm trying to sample an audio signal at a frequency of 8 kHz. Is there a way to control Wixel in order to do this? Actually I'm wondering about a function like getMicroseconds() in order to write an application similar to "test_adc" offered with the Wixel SDK.

Other ideas? It could be that I'm approaching the problem in the wrong way...

Thanks!

Tapisge]]>
Re: Operating a Wixel on the lowest possible Power!DavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152015-01-02T16:03:04-08:002015-01-02T16:03:04-08:00http://forum.pololu.com/viewtopic.php?p=42586#p42586Forum: WixelYes, the adcReadVddMillivolts function uses the 1.25 V internal reference so it should still be able to detect your battery voltage dropping. I do not see any problem with your plan to change param_lowVoltageCutoff from 2500 to 2700.

Its sounding like I need to pursue an external battery shutdown circuit, since I'll need the regulator to ensure I'm powering the wixel safely under any battery voltage condition. But in case that changes and I do remove the regulator, let me make sure I understand the A/D issues. First, you make a good point about the raw A/D counts remaining proportional to the reference voltage regardless of how that voltage changes. That that pretty much saves my potentiometer position detection scheme. Now as for detecting the low battery situation, up to now, I've been occasionally doing something like this...

Through experimentation I found that setting param_lowVoltageCutoff = 2500 would trigger my sleep call when the cell had reached 2700 (2.7V). The regulator circuit, when underpowered, seemed to reliably drop about 0.2V. Now if the regulator is removed and I power the circuit directly through the 3V3 pin, I suppose I'd have to adjust my lowVoltageCutoff to 2700, since there won't be a loss across the regulator circuit anymore. But adcReadVddMillivolts() is based on the internal 1.25V reference, so the method should still be able to detect the battery dropping, correct?]]>
Re: Operating a Wixel on the lowest possible Power!DavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152014-12-31T14:31:51-08:002014-12-31T14:31:51-08:00http://forum.pololu.com/viewtopic.php?p=42564#p42564Forum: WixelHello.

A supply voltage of 4.2 V would exceed the CC2511F32's absolute maximum rating for VDD, which is listed in Section 3 of the CC2511F32 datasheet, so it could damage the MCU if you are supplying that power directly to the Wixel's 3V3 pin without a regulator.

PeterPan wrote:2) I do the ADC in my application, both to monitor a potentiometer that is referenced to the 3V3 source, and also to monitor the supply voltage so I'll know when my battery is low and needs to be protected. I know the wixel has a lower internal regulated reference it can use, but I'd be hard pressed to get accurate potentiometer readings without another regulator in my circuit, which means I'd be back to square one, correct?

I am not sure why you think a regulator is necessary in order to get accurate potentiometer readings. If the potentiometer is powered by the same voltage that powers the CC2511F32 processor, then the raw ADC reading should stay the same even as that voltage falls. For example, if your VDD falls by 10%, then the voltage on the potentiometer's output would also fall by 10%, so the raw ADC reading should stay the same and still be a good indication of the position of the potentiometer.

3) My application already has 10K pullups on P2_1 and P2_2, and the wixel that needs the protection only transmits. Do i still need to worry about turning off the radio?

Why are you pulling up P2_1 and P2_2? For low-power operation you would want to pull down those lines or just drive them low.

The radio consumes current when it is on, so you should consider turning it off if your goal is to conserve power. You might want to calculate the amount of current that can be saved by turning off the radio and how much it would extend your battery life.

4) How do I turn off the ADC prior to sleep mode?

All the information we have about turning off the ADC can be found in the CC2511F32 datasheet. It looks like there is no special bit available that can turn off the ADC, so it probably just turns itself off after it is done performing a conversion.

5) Do I need to do anything beyond the below to go to sleep mode 2?

The code you posted looks like it will put the Wixel into sleep mode 2. To minimize the power consumption of the board while you are in that mode, I recommend referring to my earlier post on that subject:

Your code looks similar to the code in that post except there are some I/O pins that you are setting to inputs which were set as outputs in the code I posted. The reason I made those pins be outputs in that code was to prevent the extra power consumption that happens when you have an input that is at an intermediate voltage. If you want to conserve power, you should make sure that the voltage on all of your pins is either at 0 V or VDD.

--David]]>
Re: Operating a Wixel on the lowest possible Power!PeterPanhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=97412014-12-31T12:40:16-08:002014-12-31T12:40:16-08:00http://forum.pololu.com/viewtopic.php?p=42560#p42560Forum: WixelI too have been re-visiting the whole matter of putting the wixel into a minimum power mode. In my case, I'm going into permanent sleep to protect a LiPO cell from excessive drain, so it never has to come back to life until power is cycled. I'm investigating external circuits to accomplish this too, mainly to avoid having to modify the regulator on multiple wixels. I have many reasons for this, as explained below. But assuming I do the regulator modification, these are the concerns that come to mind.

1) If I power the wixel directly from the LiPO cell, it will normally see about 3.7V. But... a fully charged LiPO may output as much as 4.2V. Would you agree that this voltage might fry the MCU, or do you think it has some tolerance there?

2) I do the ADC in my application, both to monitor a potentiometer that is referenced to the 3V3 source, and also to monitor the supply voltage so I'll know when my battery is low and needs to be protected. I know the wixel has a lower internal regulated reference it can use, but I'd be hard pressed to get accurate potentiometer readings without another regulator in my circuit, which means I'd be back to square one, correct?

3) My application already has 10K pullups on P2_1 and P2_2, and the wixel that needs the protection only transmits. Do i still need to worry about turning off the radio?

thanks, and sorry if this is such a redundant question.]]>
Re: Developing Wixel Apps - QuestionPeterPanhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=97412014-12-31T11:28:34-08:002014-12-31T11:28:34-08:00http://forum.pololu.com/viewtopic.php?p=42557#p42557Forum: WixelAs David explained, the data represented by the hex codes translates to machine language, which is what the compiler (or any language compiler) must output. It would not make any sense converted to English. However, if you embed strings in your code, such as...

char * pSomeString = "Look at This!";

your translation to English, though mostly giberish, would reveal that string intact at some point. Many compilers, in fact, put all such strings in one area.]]>
Re: small increase in transmitter antenna gain possible?Jim Remingtonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=5652014-12-31T11:23:46-08:002014-12-31T11:23:46-08:00http://forum.pololu.com/viewtopic.php?p=42556#p42556Forum: WixelAntenna design, construction and impedance matching is one of the blacker arts of analog electronics.]]>
Re: small increase in transmitter antenna gain possible?PeterPanhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=97412014-12-31T11:13:56-08:002014-12-31T11:13:56-08:00http://forum.pololu.com/viewtopic.php?p=42555#p42555Forum: WixelI just want to report that I've had some limited success modifying the wixel antenna as follows. The zig-zag portion of the PC trace antenna (the side that has no connection at the board edge) was severed with a quick grind of a dremmel tool. The other half of the PC trace, that part that makes one loop and terminates at a circuit ground was left intact. The middle trace that formerly branched off in two directions was scraped to make soldering possible, and a 1/2 wavelength piece of insulated #24 wire was soldered at that point. I also coiled this short piece of wire (62.5MM) around a pencil, which resulted in about 3 turns, and then stretched it out, over a distance of about 30MM. This is similar to what tbabun did, except that I left the ground loop part of the trace intact, and used 1/2 wavelength instead of full (A full wavelength of 2.4Ghz is 125mm, so i/2 that is 62.5mm.), and I also had experimented with consolidating the wire (coiling), as described.

My tests were conducted making the above modification to a transmit only application, in which a short packet (20 bytes plus overhead) was sent 10x per second. The receive side (receive only) application simply gathered these packets, and maintained statistics based on the average LQ (radioLqi() checked after each good or bad packet receipt), the total number of packets received over the course of 2 seconds, and the total number of errant (bad checksum) errors. A baseline test was performed with the unmodified wixels separated by an ordinary house wall (plate over wood frame), about 2 meters total. This was a threshold in at which some occasional errors were expected, so I'd more easily see the positive or negative effect of each modification tested. A second test would then be done with the transmitting wixel placed 30 feet away, with two walls in-between. This was a threshold where I would begin to see as high as a 50% error rate with the unmodified wixels. My statistics were monitored by using the USB on the receive side as a virtual serial port, using a terminal program. Every two seconds, a report would be prepared and displayed.

To gauge overall quality of communication, I have to say that I have always found the LQ numbers to be all over the map. Other than statistically higher average numbers when the distance and wixel orientation is more ideal, it does not reliably correlate with the more important statistics of (a) how many packets are received within a given time frame when compared to the expected number, and (b) how many of the packets received were "good" (meaning, they did not result in an internal checksum error ( radioCrcPassed() returned 0).

So all that said, after trying several combinations of wavelength, with or without the ground loop severed, and with or without the added antenna wire coiled, and moving the transmitter antenna to a few different orientations, I found that with my 1/2 wave addition as described, there was a marked increase in the overall number of error free packets received when compared to the unmodified transmitting wixel, though I could NOT correlate this to a significantly higher an overall higher LQ statistic. This antenna combination also dropped my 50% error rate in the second test (30 feet apart, two walls between) almost half... so I'll say about a 25% error rate. Further, the coiling of the antenna extension seemed to cause the improved receiver statistics to be less affected by changes in the transmitting antenna orientation.

Interestingly, some other variations were not as promising...

> With the ground loop severed, neither a full wave nor a 1/2 wave antenna addition, coiled or not, seemed to be an improvement over the unmodified wixel. I assume this is because the loss of the PC trace ground loop put the overall antenna impedance way out of range.

> I'm not an RF engineer, and so I have no clue why this would be (perhaps impedance again), but even with the ground loop trace intact, the half wave antenna noticeably outperformed the full wave addition.

> Coiling the wire was an afterthought, to see if any added antenna was still worthwhile if it had to be crammed into a smaller space. As I mentioned, coiling the antenna did not seem to hamper the improvement at all, but it did seem to make the antenna orientation less significant.]]>
Re: Another possible low power "sleep" mode schemePeterPanhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=97412014-12-31T09:37:56-08:002014-12-31T09:37:56-08:00http://forum.pololu.com/viewtopic.php?p=42553#p42553Forum: WixelHonestly, I really wish I had a solution with fewer parts. If i could find the right MOSFET, with a higher VGS threshold of around 2.78V, I could just do this...

It wouldn't be a sharp cutoff, but it wouldn't matter because I will have already put the Wixel in sleep mode when the voltage got below 3V.]]>
Re: Another possible low power "sleep" mode schemeJeremyThttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=102522014-12-30T17:51:36-08:002014-12-30T17:51:36-08:00http://forum.pololu.com/viewtopic.php?p=42546#p42546Forum: WixelHello.

I have not thought about it too much, but with the right mix of parts, your design seems reasonable.

- Jeremy]]>
Re: Developing Wixel Apps - QuestionDavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152014-12-30T11:56:01-08:002014-12-30T11:56:01-08:00http://forum.pololu.com/viewtopic.php?p=42533#p42533Forum: WixelThat's right. However, you can have any number of C files inside your app, and the C file names do not have to match the folder name.

--David]]>
Re: Developing Wixel Apps - Questionxcaratacusxhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=148532014-12-30T11:32:39-08:002014-12-30T11:32:39-08:00http://forum.pololu.com/viewtopic.php?p=42531#p42531Forum: WixelThanks very much for replying. I worked through the "compiling a sample" app section before, but I don't think I properly understood what was going on. Having worked through it again, this is my new understanding of the procedure:

1. Develop .c file and save it in a folder sharing the same name (e.g. example.c in .../wixel-sdk/apps/example2. Run make_all.bat, which creates all of the other necessary files (including example.wxl)3. The newly created example.wxl is now ready to be uploaded

Is there anything important I'm missing, or is that all there is to it?

Thanks again,Alec]]>
Re: Voltage tolerance on ADC channelsPeterPanhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=97412014-12-30T11:29:45-08:002014-12-30T11:29:45-08:00http://forum.pololu.com/viewtopic.php?p=42530#p42530Forum: WixelIt may be irrelevant, but my wixel circuit is also powered by a LiPO cell, and I have a number of posts exploring various ways to protect my LiPO from undercharging. If that's what you're trying to do, I've had pretty good success by occasionally calling adcReadVddMillivolts(), and comparing the result to a number I store in a parameter (see example below). The normal reading will be 3.3 V, expressed as 3300. Through experimentation I've found that once the LiPO voltage gets too low to support the regulator, about 0.2V is lost across the regulator. So, if I set my "lowVoltageCutoff" to 2500, it means the LiPO has reached 2.7V, and I can choose to go into sleepMode (or take other action). Similarly, if I set my "lowVoltageWarn" to 3000, I can begin warning the user of eminent shutdown when the cell reaches about 3.2V. This has worked well and repeatably over many wixels, and may save you a few resistors. Plus, to be honest, I'm not even sure how accurately all the ADC functions work once the LiPO cell has insufficient voltage to offer the regulated 3.3V to the wixel, but the method I'm describing definitely works.

The data inside the HEX portion of a Wixel app will be written to the flash memory of the CC2511F32 when you upload it using the Wixel USB Bootloader. For a typical Wixel app, most of the data in the HEX portion will be binary instruction codes that will be executed by the CC2511F32. Different processors recognize different types of instruction codes. The CC2511F32 inside the Wixel executes 8051 (also known as MCS-51) instructions, so you have to use tools/compilers that support the 8051 architecture. The instructions are documented in the "Instruction Set Summary" section of the CC2511 datasheet.

A typical app will also store some general data in its flash memory, such as strings. If you have an ASCII string in your program then you should be able to see it in the HEX portion after converting the data in there from hex to ASCII.

More information about how the Wixel's flash memory is organized and how the bootloader works can be found in the "The Wixel USB Bootloader" section of the Wixel user's guide.

Is there a direct conversion procedure that you run on the .c file that produces the necessary block of hex?

No, the conversion process is very complicated, and should be done by a compiler like SDCC.

To convert your C program into a WXL file, I recommend following the instructions in the "Compiling an Example App" section of the Wixel User's Guide. In particular, see the "Creating Your Own Apps" subsection at the end.

If you follow those instructions, you won't need to know the details of what is inside the WXL file.

I'm new to the wixel. It seems to have a lot of potential, but the documentation on the actual process of developing an app in the user manual leaves some questions unanswered. For background, I have experience programming in some higher-level languages (some C++, lots of MATLAB), but not much on the nitty gritty computer science stuff. Anyhow, my question primarily pertains to the hex section of the .wxl file. I've already studied the Wikipedia page on Intel Hex formatting, so that part makes sense, but I'm not clear on the actual hex data the file contains. I converted the data components of one of the sample programs into ASCII (after breaking down the Intel Hex) and got what appears to be gibberish, so I assume that that's not what it is. Is there a direct conversion procedure that you run on the .c file that produces the necessary block of hex? I'm essentially at the stage where I fully understand how the .c program needs to go, but don't know how to actually produce a .wxl file based on it.

According to section 6.10 of the CC2511F32 microcontroller datasheet, the max input voltage for an ADC channel is VDD (2V to 3.6V). On the Wixel, VDD is supplied from the on-board 3.3V regulator. Since the voltage of an 1S LiPo battery significantly exceeds that when fully charged, I recommend using a voltage divider for measuring your battery's voltage.

- Jeremy]]>
Another possible low power "sleep" mode schemePeterPanhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=97412014-12-29T14:03:50-08:002014-12-29T14:03:50-08:00http://forum.pololu.com/viewtopic.php?p=42504#p42504Forum: WixelMy project involves a lot of Wixels powered by single LiPO cells, and I need to reliably cut power as completely as possible if the source voltage drops to around 3V. Otherwise I risk damage to the cells. Originally I was just going into Sleep mode, but the best i can do with an un-modified Wixel is still over 80 uA, which will still eat away at the cell if the circuit is left unattended for weeks.

Now I know snipping the regulator will allow for a much lower current, but this is a difficult and error prone task, and then I would need an external regulator (a completely charged LiPO may be 4.2V, higher than the CPU would tollerate). So long story short, I'm trying to develop an external method of shutting down the wixel, and this is my idea. If anyone can see any problems, or better yet see a way to do this with even less parts, please comment!

The idea is this.

1) On power up, the P Channel MOSFET should turn on, because the capacitor will take time to charge, thus holding the gate voltage low for a second or two. The MOSFET I'm thinking of using is a low voltage and low "on resistance" power MOSFET by International Rectifier: IRLML6401 (info here: http://www.irf.com/part/_/A~IRLML6401 )

2) Before the voltage on C1 can rise appreciably, the wixel (MCU) will be running, and immediately output a voltage on an I/O point, connected to the NPN transistor. This should keep the MOSFET's gate voltage low and keep the power to the wixel on. Note, that transistor "should" also prevent leakage through the wixel's I/O outputs when the device is un-powered. (I guess I could have used a FET for that one too)

3) The wixel will continually monitor its regulated 3V3 voltage using standard ADC calls. When the LiPO cell really starts getting low, this will drop below the 3.3V point. I'll first respond by alerting the user of eminant shutdown, and soon will set all my I/O I/O to "inputs" and drop into sleep mode. This should remove the bias on the NPN transistor, allowing C1 to charge. Very soon here won't be enough gate voltage to the MOSFET, and it will turn off.

4) I would think at that point, I should be down to nano amps, the combined leakage of the two transistors in the circuit. Certainly way better than the 80uA I was dealing with before.

5) To reset (hopefully after a battery charge), the user would just have to open the switch long enough for the charge on C1 to naturally dissipate. I suspect several seconds should do it, but a high value bleed resistor might be needed

I confess haven't tested any of this yet, and am hoping to get some "sanity check" ideas before I start gathering parts. In particular, if this can be done with less parts, I'd like to know. I'm already employing a MAX1555 IC, along with a couple more resistors and caps to handle safe charging for the LiPO cell, from an external 5VDC source, and so the extra circuitry needed to use a LiPO cell has already become more elaborate than I'd originally hoped. And if its a dumb idea, feel free to shoot! ]]>
Voltage tolerance on ADC channelssyntaxerrhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=147822014-12-27T13:34:52-08:002014-12-27T13:34:52-08:00http://forum.pololu.com/viewtopic.php?p=42489#p42489Forum: WixelI was curious if anyone knows if the ADC channels (p0_0 - p0_5) are tolerant of voltages up to 3.7vdc? I want to measure the voltage of a lipo battery that goes up to 3.7vdc since the VIN pin can't be used to measure (unless I've missed something). I know I could use a voltage divider to bring it down to 3.3v, but if it's not necessary, I'd rather not add any more bulk to the project.

Thanks in advance!]]>
Re: Writing to flash programaticallyPeterPanhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=97412014-12-22T09:21:33-08:002014-12-22T09:21:33-08:00http://forum.pololu.com/viewtopic.php?p=42428#p42428Forum: WixelI already have defaults placed when the program starts. In fact those defaults are always available to the user to implement a kind of "factory reset". But it would be nice to retain the values, and what you described seems like an excellent idea! Thanks for that!]]>
Re: Writing to flash programaticallyDavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152014-12-20T14:19:54-08:002014-12-20T14:19:54-08:00http://forum.pololu.com/viewtopic.php?p=42411#p42411Forum: WixelHello. Would it be good enough if every time you loaded the app, that 1 KB block of configuration data was reverted to some reasonable defaults? If so, then I would recommend putting those defaults into your program source code so that they get included in the HEX file.

The Wixel software has no option to preserve certain regions of flash. If you need the existing configuration data to be preserved when loading an app, then I would recommend writing a custom script on your computer that uses WixelCmd to read the configuration data from the Wixel, combines that with the HEX file for your compiled program, and then writes it to the Wixel using WixelCmd.

It is not possible to modify the bootloader from within an application because it is write-protected.

Although this is an old thread, its part of the same topic. Please forgive me if we've covered this before. Recall that the top 2 Kb are part of the Wixel" bootloader, and that I have permanently decided that the 1K block before the top two (flash mem starting at 0x7400), is an area I have set aside for permanent non-volitile application memory. This has become a valuable resource, both for configuration and for saving some runtime "learned behavior". The problem is, It has become a nuisance to replace all that stored data every time a new version of the app is reloaded. What could be done to avoid this issue? Some thoughts come to mind...

1) If the safeguarded area of memory limit are checked within the bootloader itself, then it would seem that as little as a one byte change to the bootloader's 8051 code might safeguard from 0x7400 instead of the current 0x7800. Since I now have the tools I need to read/erase/write to arbitrary blocks of flash, could I not read the block from the existing bootloader that contains this limit, alter it, and write it back? All at my own risk of course. This would be a pain, but I'd only have to do it once per wixel, and then the code to make the change could be backed out, and the regular application installed.

2) I'm doing all my coding on Windows XP and Windows 7 boxes. If the safeguarded area is controlled completely within the PC support files (wixelcmd.exe, wixel_usb_bootloader.dll, or perhaps some registry entries), altering one of these would be a much better solution, especially if the changes only involved the registry. (Surely the numbers aren't hard coded? )

3) As a last resort, I guess I could read the data stored in my 1K block and export it to a serial port based monitor program, and then put it back later. But this would obviously be a major "Rupe-Goldberg" method, which at best would still waste valuable Wixel code space to support.

Thoughts?]]>
Re: Tips on using A/D inputsPeterPanhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=97412014-12-20T08:08:44-08:002014-12-20T08:08:44-08:00http://forum.pololu.com/viewtopic.php?p=42408#p42408Forum: WixelThanks David... Looking at my own code, I see where I was already setting all the inputs with setDigitalInput( pin, PULLED). I don't know why I somehow though it was global to all pins on a port. I guess i was thinking of the direction (pulled up or down) that had to be common. So this worked out well!

By the way, sorry for the Acronym. TRS just means a "TIP-RING-SLEEVE" jack or plug, 1/4", 1/8", or a "sub-mini" (abouth 1/16" diam.), and its usually referring to round "phone" style connectors. "Phone jack" dates back to the days when telephone operators made manual connections, though these days its mostly used for musical instruments or headphones. Its just a simple way of telling how many condutors are available. In fact, now there are "TRRS" jacks and plugs, squeezing 4 connectors total onto the jack/plug.]]>
Re: Tips on using A/D inputsDavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152014-12-19T13:37:08-08:002014-12-19T13:37:08-08:00http://forum.pololu.com/viewtopic.php?p=42400#p42400Forum: WixelHello.

You can disable the pull-up resistors on individual pins using the setDigitalInput function from the Wixel SDK. I would recommend disabling the pull-up resistor on each pin that reads a potentiometer, but if you leave it enabled then the only problem would be that the pull-up resistor would somewhat distort the reading from the potentiometer.

The electrical characteristics of the CC2511F32 ADC can be found in section 6.10 of the datasheet. It says the input resistance is typically 197 kilohms. A 1k or 10k resistor protecting the analog input should probably be OK, with higher the resistances having a larger effect on ADC readings, but I have not tried it.

I am not familiar with closed circuit TRS jacks, but if that kind of jack connects the signal to 0V when the cable is removed then that sounds good. If you do not have a pull-up or pull-down resistor and you do not use a jack like that, then the input would be floating when the potentiometer is disconnected and give unpredictable readings. This might be bad or confusing depending on what you are doing with the readings.

--David]]>
Tips on using A/D inputsPeterPanhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=97412014-12-19T10:26:44-08:002014-12-19T10:26:44-08:00http://forum.pololu.com/viewtopic.php?p=42394#p42394Forum: WixelI have an existing project in which I would like to add some A/D capability, and am just looking for some pointers and "gotchas". basically all I want to do is sense an input from a LINEAR taper potentiometer, with the Wixel 3.3V supply and 0 volts on the outer legs, and the wiper fed to an A/D input. I actually only need a 0-64 count for what I'm doing, so the Wixel A/D resolution is more than sufficient. Some questions come to mind which are not so clear from the example.

1) I only want to to read A/D inputs on P0-2 and P0-3. The other P0 inputs are already being used by the existing app as digital inputs, and those require the pull up resistors configured. So I think I have some conflicts already. Is it possible to just configure 1 or 2 of the available P0 inputs for A/D use, or must I configure all of the P0 bits this way? Perhaps its not a big deal to continually switch configurations under program control? I've done this to multiplex between driving LEDs and sensing buttons, but haven't tried this with an A/D situation. Surely there would be some settling time issues?

2) Assuming the pins configured to be floating (pull ups and pull downs disabled), how high is the impedance of the pins configured to be A/D inputs? I'd like to isolate the Wixel input from the pot I'm measuring with a resistor to add a little safety, and maybe even add a capacitive low pass filter, so i need to understand what kind of "load" I'm driving.

3) Lets say in the above case that the Pot is external, and may be unconnected sometimes. Would it be advisable in that case to use something like a closed circuit TRS jack, in which the input is grounded to 0V when the pot is disconnected?]]>
Re: sending and receiving between two wixelsElinushttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=116142014-12-14T00:58:48-08:002014-12-14T00:58:48-08:00http://forum.pololu.com/viewtopic.php?p=42296#p42296Forum: WixelOK, thought I'd best check before trying to reinvent the wheel! Thanks, Dave.]]>
Re: sending and receiving between two wixelsJonathanKoshhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=92692014-12-12T17:06:14-08:002014-12-12T17:06:14-08:00http://forum.pololu.com/viewtopic.php?p=42285#p42285Forum: WixelUnfortunately, we do not have a single app that does that, but you could use our Wixel SDK, which has the source code for both of those apps, to write your own app.

-Jon]]>
Re: sending and receiving between two wixelsElinushttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=116142014-12-12T01:36:24-08:002014-12-12T01:36:24-08:00http://forum.pololu.com/viewtopic.php?p=42267#p42267Forum: WixelHi,

Do you know if there is an app available that combines the functionality of the wireless_serial app and the usb_com app so I can send commands form wixel A to have them executed on Wixel B ?

ThanksDave]]>
Re: sending and receiving between two wixelsElinushttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=116142014-12-12T00:32:11-08:002014-12-12T00:32:11-08:00http://forum.pololu.com/viewtopic.php?p=42266#p42266Forum: WixelThanks Jon,

I have that working now.

Dave]]>
Re: sending and receiving between two wixelsJonathanKoshhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=92692014-12-11T17:41:19-08:002014-12-11T17:41:19-08:00http://forum.pololu.com/viewtopic.php?p=42260#p42260Forum: WixelHello, Dave.

You can test the wireless capability of your Wixels by connecting both of them to your computer and using a terminal program like our Serial Transmitter Utility, which lets you transmit sequences of bytes to a selectable COM port. Note, if you use the Pololu Serial Transmitter Utility, you would have to open two instances of the program, one to transmit and one to receive.

If that is not working, you should make sure that the baud_rate, and radio_channel parameters are the same for each Wixel, and that both Wixels are in the correct serial mode (or both in Auto-Detect).

-Jon]]>
sending and receiving between two wixelsElinushttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=116142014-12-11T03:36:31-08:002014-12-11T03:36:31-08:00http://forum.pololu.com/viewtopic.php?p=42242#p42242Forum: WixelHi,

I have recently bought two wixels. my eventual aim is to have one as a master on my 3pi and the other connected to a pc. for the 3pi wixel to transmit sensor readings to the pc where a vb app will display them and also have the ability to take control of the 3pi and drive it using the arrow keys.

however, I first want to test the wireless data transfer.

I have loaded the wireless serial app to both (they are both in the same pc one on Com7 the other on Com8)how do i then send a test string from one to receive it on the other?

I have tried using telnet software and also a simple vb app to open the ports and writing data to them that way but I am getting no where.

can anyone point me in the right direction please?

Thanks in advanceDave]]>
Re: Operating a Wixel on the lowest possible Power!BrandonMhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=109542014-12-10T14:32:58-08:002014-12-10T14:32:58-08:00http://forum.pololu.com/viewtopic.php?p=42231#p42231Forum: WixelHello.

No progress has been made on that yet.

By the way, that thread was started in 2011; I think you might have mistaken the date the original poster joined the forum with the date it was posted.

-Brandon]]>
Re: Operating a Wixel on the lowest possible Power!Burkehttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=85602014-12-10T08:30:01-08:002014-12-10T08:30:01-08:00http://forum.pololu.com/viewtopic.php?p=42220#p42220Forum: WixelThe thread you referred to is from back in 2008. At that time they seemed to be discussing including the ability to use sleep modes into the standard Wixel SDK. Has that been accomplished? If so, where do I find its documentation?]]>
Re: which version of wixel should I use?tzachihttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=134612014-11-25T23:44:00-08:002014-11-25T23:44:00-08:00http://forum.pololu.com/viewtopic.php?p=41996#p41996Forum: WixelThanks for the information that you have provided.

I'm using the dexcom g4 as a transmitter and the wixel as a receiver. I have already tried one of this and it works.

ThanksTzachi]]>
Re: which version of wixel should I use?BrandonMhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=109542014-11-25T17:19:49-08:002014-11-25T17:19:49-08:00http://forum.pololu.com/viewtopic.php?p=41989#p41989Forum: WixelHello, Tzachi.

The only difference between the unassembled Wixel and the fully-assembled Wixel is that the fully-assembled version comes with the header pins pre-soldered whereas the unassembled version comes with loose headers. Are you planning on using another Wixel as a wireless transmitter? If not, I am also curious what kind of wireless transmitter are you trying to use with the Wixel.

-Brandon]]>
Re: which version of wixel should I use?Jim Remingtonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=5652014-11-25T17:06:46-08:002014-11-25T17:06:46-08:00http://forum.pololu.com/viewtopic.php?p=41985#p41985Forum: WixelWhat wireless transmitter? Wixels work only for certain types of data transmissions and only for a limited number of radio frequencies in the 2.4 GHz band, usually those used by another Wixel.]]>
which version of wixel should I use?tzachihttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=134612014-11-25T14:39:13-08:002014-11-25T14:39:13-08:00http://forum.pololu.com/viewtopic.php?p=41981#p41981Forum: WixelI would like to use a wixel in order to receive data (from a wireless transmitter) and read it using the USB port.

I don't intend to connect it to anything else.

Can I do it with the normal wixel or should I buy the fully assembled version?

When I started messing with the modifier all kinds of interesting things began to happen and they were not things I wanted to happen. :) I was able to work out how to send an uppercase letter. The code is below if anyone is interested.

]]>
Re: USB HID sending a key code...DavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152014-11-16T16:45:11-08:002014-11-16T16:45:11-08:00http://forum.pololu.com/viewtopic.php?p=41881#p41881Forum: WixelI think it is sufficient to send one frame of input where both shift and "F" are pressed, and then later send a frame where they are both released. There are key codes for shift, but you could also just set the approriate bit in the "modifiers" field, which is documented here:

The sendKeyToUSB function tells the computer that the key is being pressed, but your app does not have any code to tell the computer that the key has been released. Your app would need to wait until usbHidKeyboardInputUpdated has changed back to 0, then set keyCodes[0] back to 0 and set the flag to 1 again.

Your current program is actually just holding down the Print Screen button and your computer is probably busy making screenshots.

I want to send a single key code ('F') to the USB HID via an interrupt on port 0 pin 0. The interrupt code works.

When I add the send key code, something is sent to the PC. The PC becomes very slow, CPU usage jumps to 50% and the only way to get control of the PC is to uninstall the HID drivers the Wixel installs.

]]>
Re: Setting up an interrupt...DavidEGraysonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=10152014-11-10T12:18:14-08:002014-11-10T12:18:14-08:00http://forum.pololu.com/viewtopic.php?p=41800#p41800Forum: WixelThe SFRBIT macro is not documented at all because it is not intended to be used outside of cc2511_map.h. That macro uses the __sbit keyword. The documentation of __sbit in the SDCC Manual (version 3.4.1, section 3.5.1.7) says:

Special function registers which are located on an address dividable by 8 are bit-addressable, an __sbit addresses a specific bit within these sfr.

Since you are enabling interrupts on four pins (P0_0, P0_1, P0_2, and P0_3), you probably need to clear the P0IFG flags for all of those pins in your ISR or else you risk getting stuck in the ISR forever. After clearing those, it looks like you need to clear IRCON.P0IF. During initialization, you should write "EA = 1;" to explicitly enable interrupts instead of depending on the Wixel libraries to do it for you. The P0_0_interrupt variable should be volatile. There might be more issues that I have not thought of.

The SFRBIT macro can only be used with SFRs with an address that is a multiple of 8. You should use the definitions provided by cc2511_map.h to access PICTL and P0IFG. If you continue to have trouble, please post a description of how you are testing the code along with the expected behavior and the actual behavior.

--David]]>
Setting up an interrupt...Mark-http://forum.pololu.com/memberlist.php?mode=viewprofile&u=135882014-11-09T10:28:23-08:002014-11-09T10:28:23-08:00http://forum.pololu.com/viewtopic.php?p=41790#p41790Forum: WixelHello,

I am new to the Wixel and TI processor line. Also I have only done a few projects (3) and they used PICs.

Thanks for the answer. The ADC actually works as expected, nothing puzzling. It was all related to the way I call the adcReadVddMillivolts() function. Still haven't figured out though what actually happened but it's for another time.

The ADC functions we provide for the Wixel modify the ADCCON3 register, so you might try setting that register to its default value of 0 before going back to sleep. Also, are you sure you are just performing one ADC conversion? If the Wixel is waking up from PM2 regularly and performing a converison each time it wakes up, that would cause the average current draw to increase. If that doesn't help, you could post a minimal program that reproduces the issue, and I might be able to see what is wrong.

I'm working on project that requires power savings and the Wixel needs to be regularly put in low power mode (sleep mode PM2). I mesure a current of around 90 microamps in this mode, which I suppose is around the lowest possible from what I read in relative threads. The problem comes when I initiate a single ADC conversion to measure VDD (I use adcReadVddMillivolts()) while the Wixel is "awake", as then, in PM2, I measure a current of around 300 microamps!

It sounds like you are using the Wixel's Serial-to-I²C App and it is taking an average of 5 milliseconds to read some data from your MinIMU-9 v3. How fast do you want to read the data?

What settings did you choose for the Wixel Serial-to-I²C App? There is a parameter called I2C_freq_kHz that controls the speed of the I²C communication, which defaults to 100. Both chips on the MinIMU-9 v3 are compliant with fast mode (400 kHz) I²C standards, so you could try changing the parameter to 400 and see if that helps. You could also try setting it higher than 400 since our Wixel I²C code tends to overestimate the delays needed between bits, making the signal slower.

I recommend that you don't use blocking loops like the while(nBytesAvailable<6) one because it could waste CPU time and the call to ClearCommError in the loop might be causing a delay. Instead, I would recommend that you configure the serial port file handle so that you can do blocking reads and writes on it with ReadFile and WriteFile. This means that all the data would be transferred before the function returns and you would not need a loop to wait for the data. We provide some example code for doing this in the "Windows C" section of the Maestro Servo Controller User’s Guide.

When you expand this program to read from the accelerometer, gyro, and accelerometer, you might consider sending all the commands needed to read from those devices with one call to WriteFile. That will probably increase the throughput because all your command bytes can be sent together in one USB packet if they do not exceed 64 bytes in length. Also, you could try reading the results with a single call to ReadFile.

If it is not fast enough after doing all that, you could make your own Wixel app that reads the data and reports it to the computer, avoiding the need to call WriteFile in the PC software.

--David]]>
Re: i2c woesgcl8ahttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=134992014-10-12T03:35:18-07:002014-10-12T03:35:18-07:00http://forum.pololu.com/viewtopic.php?p=41430#p41430Forum: WixelThanks fo the reply. I discovered the problem, which is that the i2c library always expects the number of bytes to be written or read, so I need to send 'S', 0x4E, 0, 'P' to the Wixel so that it skips the data transfer. When I sent 'S', 0x4E, 'P', it was waiting for 50 data packets (the numerical equivalent of 'P').]]>
Re: i2c woesJim Remingtonhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=5652014-10-11T20:13:11-07:002014-10-11T20:13:11-07:00http://forum.pololu.com/viewtopic.php?p=41429#p41429Forum: Wixel

The _first_ time I send the characters SNP, an oscilloscope shows that the Wixel _correctly_ sends a start command, 0x4E, stop command. The 0x4E commands the HIH-6130, which has address 0x27, to take a measurement.

When/how do you send the device address? You should describe the entire sequence of events.]]>
i2c woes - RESOLVEDgcl8ahttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=134992014-10-11T06:18:56-07:002014-10-12T03:35:44-07:00http://forum.pololu.com/viewtopic.php?p=41426#p41426Forum: WixelHaving some i2c frustration. Trying to interface with SparkFun's HIH-6130 humidity sensor. I've successfully connected to it directly with an Arduino, so I know the HIH-6130 board is working. I've tried two different Wixel's with the attempts below, so it's not a bad Wixel. I'm running the serial_i2c app unmodified, Wixel connected via USB, 9600 baud, interface_mode = 2 (USB).

With the Wixel connected via USB, I open CoolTerm. The _first_ time I send the characters SNP, an oscilloscope shows that the Wixel _correctly_ sends a start command, 0x4E, stop command. The 0x4E commands the HIH-6130, which has address 0x27, to take a measurement.

The next command, whatever it is, fails. If, for example, I try to send SNP again, the Wixel tries to send three bytes on the i2c bus: 0x53, 0x4E, 0x50, corresponding to 'S' 'N' 'P' (with no starts and stops!). The red LED comes on, indicating an error condition, but when I send E to the Wixel, corresponding to a request for errors, instead of returning the error condition, it tries to send 0x45 ('E') _on the i2c bus_. No matter what I do, it never recovers from the error state, and it never actually tells me the error.

Any ideas?]]>
Re: Communication Speed I2C Wixel App with MiniIMU-9ScottyChunghttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=134672014-10-10T12:17:38-07:002014-10-10T12:17:38-07:00http://forum.pololu.com/viewtopic.php?p=41410#p41410Forum: WixelI am using the Pololu Wixel Configuration Utility to upload the Serial-I2C app to the Wixel. I have not downloaded the source code for the app just the .wxl file from the user manual.

I discovered this issue of the seemingly random order of data being received. It was just an error status byte not being read.

I put together this short example that I believe is replicating the communication speed issue I am having.This takes a time of about 5 seconds to read. However, for my actual research we are also reading the accelerometer at the same rate and the magnetometer at a reduce rate so the end speed is slower than desired.

]]>
Re: Long-term connected Wixels radio issueururkhttp://forum.pololu.com/memberlist.php?mode=viewprofile&u=129482014-10-08T12:36:33-07:002014-10-08T12:36:33-07:00http://forum.pololu.com/viewtopic.php?p=41361#p41361Forum: WixelAfter receiving a helpful email from David, I went ahead and made some recommended changes to our code. It has only been running for a few hours, so we won't know immediately if it fixes our problem. It is related to how calibration is triggered - a Wixel that only receives will not recalibrate itself until it is rebooted (which ours aren't).

The way we ensured calibration was by setting the RX Wixel to IDLE instead of FSTXON: