wixel-sdk
wixel-sdk copied to clipboard
jstevensog
Battery Level
Hello, I know this has been discussed a bit, but just curious what the software side of the Wixel is doing with the xBridge2 27K/10K voltage divider, and what the levels are. 4.2V with a 27K/10K comes out 1.135V on the analog input of the Wixel. 3.0V (battery turns itself off) comes out 0.811V on the Wixel. So that is 0.324V range only. Just curious why these resistors were chosen. Wixel is 7bit to 12bit resolution I believe, what resolution is being used for this? 0-128 or 0-4096, or something in between?
Wixel Analog input is 0-3.3V, and we are using at best 0.811-1.135V. Can we improve this?
For example if it was changed from 27K/10K, to be 4K/10K, then 4.2V would be 3.0V on the Wixel 3.0V would be 2.143V on the Wixel giving 0.857V range, instead of 0.324V range.
Could likely even be better than this, but this is just an example..
Maybe 3.3V is the 0% limit, given that is what the reference is based on, I am not sure.
Like my battery currently is 4.11V and its saying 80%, when in reality its more than that.
Can you tell me where in the software these bits are and if they are changeable, so I can experiment with different resistor values? Does the xBridge2 send the 0-100% reading to the xDrip/xDrip2, or is the 0-100% calculated in the xDrip/xDrip2 application itself?
Thanks
oh hmm. is the Internal Reference 1.25V for the Wixel, not 3.3V ? Ok that explains a few things.
Hi there, The resistor values were chosen for only two reasons.
- The highest resistance possible to reduce drain on the battery.
- The lowest resistance possible to allow the ADC capacitor to charge, and thereby read the voltage.
The only other consideration is that the values must be standard resistor values.
The upper and lower values for the calculation of % of battery are all in the defines at the top of the source code (BATTERY_MAXIMUM (1814) //4.1V and BATTERY_MINIMUM (1416) //3.2V), and are clearly marked, along with the calculations to determine them.
There is no value in lowering the resistors, or trying to increase the voltage range out of the divider circuit. Using voltage to measure LiPo battery capacity is NOT accurate in any way shape or form. There is not a linear relationship between the voltage being delivered by the battery, and the remaining capacity of the battery. The voltage drops rapidly from ~4.2V, flattens out, then falls quickly as the battery capacity drains and the voltage drops to 3.3V.
It is only an indication, not an accurate calculation based on current in/current out as in a mobile phone. Such circuitry is beyond what is available off the shelf, which would preclude this being assembled by non-technical people.
You should also note that LiPo cut off is NOT always accurately 3.0V. Some cut off above this, and some cut off below. Same with the 4.2V maximum. Which is why there is a "learning" algorithm in the code and the 4.1V initial maximum value and 3.2V initial minimum value. As the voltage goes higher than this, the new "maximum" value is saved in flash. Similarly, the lower limit set in code is learned, but this is limited to ensure the wixel does not "die" in the middle of writing to flash (quite dangerous).
I hope this assists with your understanding. Cheers
On Mon, Feb 6, 2017 at 11:28 AM, WanaGo [email protected] wrote:
Hello, I know this has been discussed a bit, but just curious what the software side of the Wixel is doing with the xBridge2 27K/10K voltage divider, and what the levels are. 4.2V with a 27K/10K comes out 1.135V on the analog input of the Wixel. 3.0V (battery turns itself off) comes out 0.811V on the Wixel. So that is 0.324V range only. Just curious why these resistors were chosen. Wixel is 7bit to 12bit resolution I believe, what resolution is being used for this? 0-128 or 0-4096, or something in between?
Wixel Analog input is 0-3.3V, and we are using at best 0.811-1.135V. Can we improve this?
For example if it was changed from 27K/10K, to be 4K/10K, then 4.2V would be 3.0V on the Wixel 3.0V would be 2.143V on the Wixel giving 0.857V range, instead of 0.324V range.
Could likely even be better than this, but this is just an example..
Maybe 3.3V is the 0% limit, given that is what the reference is based on, I am not sure.
Like my battery currently is 4.11V and its saying 80%, when in reality its more than that.
Can you tell me where in the software these bits are and if they are changeable, so I can experiment with different resistor values? Does the xBridge2 send the 0-100% reading to the xDrip/xDrip2, or is the 0-100% calculated in the xDrip/xDrip2 application itself?
Thanks
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jstevensog/wixel-sdk/issues/24, or mute the thread https://github.com/notifications/unsubscribe-auth/AIQs8_6swsIQpl7fEm1PbfiKaT0g8Tvcks5rZmkVgaJpZM4L3rr9 .
-- John Stevens "You are how you live, not what you have."
Thanks very much. I just found the bits in the code a moment ago and tried to find the formula being used (rather than just stated in comments) but havent spotted it yet. But what you have said sounds good anyway. Yes aware the drain is not linear on these batteries.
Understand it was made so non technical people can build and use without too many issues, but for those of us who want to take it a step further, I was just curious if there are better ways of doing it.
I am no expert on the wixel at all, but am comfortable with hardware. A battery management chip would be ideal, one with battery gauge, but implementing the comms to it in the wixel I am stuck on. I saw in another issue post about I2C options, but it was mentioned the flash/ram space is likely limited.
Finding one which doesnt talk I2C but instead outputs a linear analog voltage which the Wixel could then read, would be nice to find. 0-1.25V is a bit sad on the Wixel side though.
Would be really neat to make a techy version of the xBridge which is more of a challenge for those who want to do it, if there is an advantage of doing so.
Appreciate the response anyway, thanks.
Its just curious as my Battery is sitting at 4.18V, fully charged. 3.3V rail on Wixel is bang on 3.3V. ADC is reading 1.134V, yet xDrip+ is show xBridge Battery: 80% Is this due to the learning algorithm or something? I would have thought since my battery is over 4.1V it should be reading 100%. If the maximum is adapting and it thinks it should be higher to be 100%, how do you restart the process?
I leave my xBridge2 powered while charging, could this have affected the logic for max stored in Flash ?
Thanks
Ideally, we would replace the Adafruit board with a device that included a Qi and USB LiPo charger with inbuilt battery monitoring, and either a SPI or I2C interface for polling it. There are certainly the chip sets around that include all these features, but I am not so sure of the linear voltage output devices. I am (very slowly) working on two hardware projects. One, being a bridge hardware design that includes everything on one board, and is firmware updatable via BLE. This would include the charger/monitor on the board. The other is a Qi chargeable battery system for the G4/5 transmitters that can replace the current silver oxide cells. Once completed I will open source them, which will allow national groups to arrange getting them made up and distributing them to those that want them.
But work and other things are getting in the way of me completing these. It is also getting in the way of my finishing the channel scanning algorithm for xBridge that would see much better packet capture. And that is a much more important piece of work right now.
Happy to collaborate on a new hardware design. The current one is simple and elegant, but the software needs more work on the packet capture and data logging side, which will really improve many things. But, I agree, we need something a bit more technical, well made, and less prone to damage. Were this project not a DIY, I would never have released this hardware design as is. Cheers
On Mon, Feb 6, 2017 at 11:57 AM, WanaGo [email protected] wrote:
Thanks very much. I just found the bits in the code a moment ago and tried to find the formula being used (rather than just stated in comments) but havent spotted it yet. But what you have said sounds good anyway. Yes aware the drain is not linear on these batteries.
Understand it was made so non technical people can build and use without too many issues, but for those of us who want to take it a step further, I was just curious if there are better ways of doing it.
I am no expert on the wixel at all, but am comfortable with hardware. A battery management chip would be ideal, one with battery gauge, but implementing the comms to it in the wixel I am stuck on. I saw in another issue post about I2C options, but it was mentioned the flash/ram space is likely limited.
Finding one which doesnt talk I2C but instead outputs a linear analog voltage which the Wixel could then read, would be nice to find. 0-1.25V is a bit sad on the Wixel side though.
Would be really neat to make a techy version of the xBridge which is more of a challenge for those who want to do it, if there is an advantage of doing so.
Appreciate the response anyway, thanks.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jstevensog/wixel-sdk/issues/24#issuecomment-277564664, or mute the thread https://github.com/notifications/unsubscribe-auth/AIQs80mQiMQi90dTzeRjUB0MY33CD8oSks5rZnASgaJpZM4L3rr9 .
-- John Stevens "You are how you live, not what you have."
xBridge2 firmware will learn the Maximum battery voltage of your battery after a full charge. So, with it sitting on charge, and the battery fully charged, it will read 100%. Generally, as soon as you take it off charge, the battery immediately falls below maximum indicating a lower charge (mine drops rapidly to ~80% in the first 12-24 hours after being taken off charge). The two things that will influence the percent indication are the stored Maximum and Minimum battery voltage. If your charger board has delivered a voltage over 4.2V for any 5 minute period, that will be the new maximum voltage. Obviously, the other factor is the minimum voltage. If your batter still supplies the wixel at say ~3.0V, but you have never discharged the battery below the 3.2V, then obviously the voltage range is not going to be correct and may indicate a lower capacity.
Again, all this is moot as the voltage/capacity relationship is non-linear. You cannot calculate accurately the battery capacity from the voltage delivered by the battery, and each battery has similar, but not identical voltage/discharge profiles.
It is only an indication as to when the user needs to charge the bridge, not an accurate measure of the capacity of the battery, and nor can it be used to estimate time until flat.
Currently, the only way to reset the stored maximum and minimum battery voltage values is to flash the wixel again. This removes ALL the stored values, both automatically stored and stored as a consequence of issuing a configuration command.
Cheers
On Mon, Feb 6, 2017 at 12:19 PM, WanaGo [email protected] wrote:
Its just curious as my Battery is sitting at 4.18V, fully charged. 3.3V rail on Wixel is bang on 3.3V. ADC is reading 1.134V, yet xDrip+ is show xBridge Battery: 80% Is this due to the learning algorithm or something? I would have thought since my battery is over 4.1V it should be reading 100%. If the maximum is adapting and it thinks it should be higher to be 100%, how do you restart the process?
I leave my xBridge2 powered while charging, could this have affected the logic for max stored in Flash ?
Thanks
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jstevensog/wixel-sdk/issues/24#issuecomment-277566318, or mute the thread https://github.com/notifications/unsubscribe-auth/AIQs8zha4nLB_38emzdjhcI0kQoMymVqks5rZnUXgaJpZM4L3rr9 .
-- John Stevens "You are how you live, not what you have."
Hi John This all sounds awesome, and yes I 100% agree with the packet capture stuff and how it is the most important. Regarding the battery % thing, I left it charging for hours and it was sitting at full charge of 4.21v for quite a long time. xDrip+ still reported 80% though. Couldnt get it to budge and change to 100%. Ended up reflashing the Wixel and that solved the problem. Keep up the good work, I cant wait to see what comes next with all this. I am an Electronics Engineer by trade and do PCB layout/design daily using Altium, so if you would like me to join in with the new design effort, please let me know. Thanks
That would be awesome if you would like to help out with the PCB designs I have in mind. Send me a PM through gitter and we can chat about that. Cheers
On Tue, Feb 7, 2017 at 9:02 AM, WanaGo [email protected] wrote:
Hi John This all sounds awesome, and yes I 100% agree with the packet capture stuff and how it is the most important. Regarding the battery % thing, I left it charging for hours and it was sitting at full charge of 4.21v for quite a long time. xDrip+ still reported 80% though. Couldnt get it to budge and change to 100%. Ended up reflashing the Wixel and that solved the problem. Keep up the good work, I cant wait to see what comes next with all this. I am an Electronics Engineer by trade and do PCB layout/design daily using Altium, so if you would like me to join in with the new design effort, please let me know. Thanks
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jstevensog/wixel-sdk/issues/24#issuecomment-277828438, or mute the thread https://github.com/notifications/unsubscribe-auth/AIQs88GnItUlxYop8c5IQ3d7-jJW23svks5rZ5hxgaJpZM4L3rr9 .
-- John Stevens "You are how you live, not what you have."
Lurking. And super excited about your improvements @jstevensog, especially improved packet capture and battery monitoring/life. I'm keen to help with testing, or anything else you might need :)
Thanks Mark Francis, It will unfortunately be a while for me to get this all going. Work is taking way too much of my time these days. Well, that and training for cycling events. It is nice to know that xBridge still has a place. I thought it would die relatively quickly after the G5 came along. Save-CC has already done the hard work of adding in a packet buffer so you can walk away form your phone for a while (a day) and still capture your BG trends, and updating to the later wixel SDK. I just haven't had a chance to go through it, update my SDK and merge his changes in.
Packet capture algorithm change is my main coding focus when I get a window. The CC221x can do channel scanning, it is just getting all the timings right. It will open up a lot of potentials as well as improving packet capture. Like a net of receivers around a sporting field so that a team of T1Ds can all be monitored from the sidelines. Another goal I have had for a while.
I will post an issue when I have something for wider test. It has to work well for me before I inflict my code on others. Cherrs
On Tue, Feb 7, 2017 at 9:10 AM, Mark Francis [email protected] wrote:
Lurking. And super excited about your improvements @jstevensog https://github.com/jstevensog, especially improved packet capture. I'm keen to help with testing, or anything else you might need :)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jstevensog/wixel-sdk/issues/24#issuecomment-277830402, or mute the thread https://github.com/notifications/unsubscribe-auth/AIQs8xFoSqwooWM3qjHBklBolZu8EoWgks5rZ5o-gaJpZM4L3rr9 .
-- John Stevens "You are how you live, not what you have."
As long as battery life of the G4 is 4 times that of the G5 (and of course they are still being sold), xBridge will stay strong :)
Love the idea of a network of receivers too.
I hope this is a good place to report it, but I seem to have an issue on my xBridge2 circuit where the learning algorithm (which I only understand at a high level) appears to render the xBridge useless. The result is constant warnings from xDrip that my battery has dropped to an unsatisfactory level. Charging the xBridge makes no improvement to the error state, even when the hardware charger indicates the battery is charged with a green light.
This led me to believe my battery was borked. But after chatting with WanaGo offline he suggested a reflash would reset my max and min values. This worked and xDrip suddenly played nicely. A few weeks later and it's happened again.
As far as I can tell something happens when the battery goes below a certain perceived charge. From memory this latest time I got down to about 40% before it started giving me wild values, even after a charge.
At least there is a workaround, but I've already busted one solder joint dismantling my xBridge to get to the Wixel USB for reflashing.
Yeah mine has done it again too. Reflashing solves it. The code suggests (to me) if it sees a value higher or lower than the current max and min, then it saves these new readings in its place. So if there is for some reason a random reading, it seems it might save it, and then the battery values are stuffed. I dont know why or how this might happen, but it certainly seems to happen. When I reflashed it, the Wixel app said I had something like 12 bytes different between the Wixel and the code I was going to load. Unsure if this is significant.
Hi Old-square-eyes, This is unlikely to be an problem with the algorithm itself. I have run my xBridges for over 2 years without ever seeing this issue. However, the algorithm is not perfect, so there could be something going on. But I believe it may be to do with the voltage divider rather than the software.
The algorithm prevents writing to the wixel flash if the battery is considered too low a voltage. So, going flat with the bridge should not cause this issue. However, there is no such limit on the High voltage limit. It can learn up until the point that the wixel analogue input voltage fries the wixel.
I would recommend carefully checking the area around the voltage divider to ensure there is no possibility of the 27k resistor being shorted out by anything. This would cause the high limit to be recorded at 3.3v, which is way higher than the 1.13V it is expecting. If the 3.3V value was recorded, then that would certainly cause the capacity calculation to report the voltage being too low.
I will put in a hard limit of 4.5V in my next iteration of the code to prevent this happening. But until then, I would definitely check that there is no possibility of the 27k resistor being shorted out.
Feel free to send through a photograph of the voltage divider for me to look at for you, in case my old eyes may see something yours missed. The magnifiers I need to use these days are very strong. So if you can get a pretty good quality shot, it will help me no end ;) Cheers
On Mon, Feb 20, 2017 at 9:58 AM, old-square-eyes [email protected] wrote:
I hope this is a good place to report it, but I seem to have an issue on my xBridge2 circuit where the learning algorithm (which I only understand at a high level) appears to render the xBridge useless. The result is constant warnings from xDrip that my battery has dropped to an unsatisfactory level. Charging the xBridge makes no improvement to the error state, even when the hardware charger indicates the battery is charged with a green light.
This led me to beleive my battery was borked. BUt after chatting with WanaGo offline he suggested a reflash would reset my max and min values. This worked and xDrip suddenly played nicely. A few weeks later and it's happened again.
As far as I can tell something happens when the battery goes below a certain perceived charge. From memory this latest time I got to about 40% before it started giving me wild values, even after a charge.
At least there is a workaround, biut I've already busted one solder joint dismantling my xBridge to get to the Wixel USB for reflashing.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jstevensog/wixel-sdk/issues/24#issuecomment-280957094, or mute the thread https://github.com/notifications/unsubscribe-auth/AIQs82ZrWCz_IVQ9Kkel3OOcXXTOtgIPks5reMkngaJpZM4L3rr9 .
-- John Stevens "You are how you live, not what you have."
I have heat shrink over my resistor configuration. I'll try to get a picture when I next have everything splayed out - which should be soon since I need to re-solder a joint.
It might also be worth noting I'm using Chinese copy charger and Bluetooth units. These could be failing of course. But they work perfectly fine after a reflash (as does @WanaGo's by the looks - who is on official hardware).
Hi All, OK, WanaGo, that solder joint to GND on the 10k resistor looks very suspect. I deliberately do NOT use SMD resistors as they are difficult to get an adequate solder joint with them and ensure there is no damage to them. Would rather sacrifice some room and use standard metal film resistors to be sure of the connection. They are small enough and can be easily soldered under the wixel without occupying too much room. Like this.
If the 10K comes loose from the GND, this will also drive the input to 3.3V (or whatever the battery voltage is at the time) and be recorded as the upper limit for the battery capacity algorithm. And that would definitely cause you problems. This would also explain the intermittent nature of the issue. If the joint is not that good, or the SMD resistor cap has become somewhat loose or damaged, some pressure in the right direction would make it come adrift and the 3.3V (or higher) recorded as the upper limit. Once you reflash, that resets the default values, and to do that you need to pull the wixel out of your casing. Which would relieve any pressure on these resistors/joints and perhaps allow them to make ok contact again.
Really, whilst I admire the skill and desire to make the bridge smaller using these, I do not recommend it. They are far too difficult to ensure a good solder joint by hand, and far too easily damaged if they are not mounted on a circuit board and soldered to it on both ends.
I am fairly certain that this will be the source of the issue.
As I have said, I have used standard metal film resistors in every bridge I have made for myself and others. Not one of them has exhibited this issue. The only difference I see is the use of these SMD resistors, which do have inherent issues for hand soldering to a board like the wixel, without the proper pads for mounting/soldering at both ends. If you want to continue to use these, it would be best to have a small PCB made with the voltage divider on it, and then solder that to the wixel.
Hope this helps. Cheers
On Mon, Feb 20, 2017 at 11:14 AM, WanaGo [email protected] wrote:
Here is mine, I am using SMT 0603 resistors and a little wire. [image: image] https://cloud.githubusercontent.com/assets/759846/23108194/6e310b84-f76e-11e6-95b1-2f3ee69af1a9.png [image: image] https://cloud.githubusercontent.com/assets/759846/23108202/8e70d41a-f76e-11e6-8a0f-bd207637fd99.png
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jstevensog/wixel-sdk/issues/24#issuecomment-280961692, or mute the thread https://github.com/notifications/unsubscribe-auth/AIQs83p8xzKzd9NHjJIpPtm2nSR9u5-aks5reNsDgaJpZM4L3rr9 .
-- John Stevens "You are how you live, not what you have."
Hi John
Sorry but that is not the issue. I hand solder 0402's all the time, these 0603's are large and there is nothing wrong with the soldering. They are rock solid, there is good solder coverage and there are no shorts. I have looked at these under a 20x lens and there is nothing wrong with them at all.
Side note, old square eyes is using standard metal film resistors and has the same exact problem, so I think its safe to say the problem isnt the SMT resistors.
Also, that little piece of solid core wire, is solid... and with 2 resistors between it and the pads, it does not budge at all.
Ok, but I would still not use them. They can be easily damaged, and you cannot see that under any magnification. I guess we are at somewhat of a stalemate. As I have said, non of the bridges I have made have ever exhibited this problem, and one of them is well over two years old (currently in use by myself). The only other possible explanations, and difficult to validate or diagnose, are:
- An intermittent power issue whilst the wixel is writing the Upper or Lower voltage divider value to flash.
- Some fault in the wixel, causing the value to be saved incorrectly in RAM rather than Flash.
1 is definitely a possibility, and you could at least check it by dumping the wixel program out to a different file when you have the issue, and before you reflash. The voltage limits and other flash saved settings appear in the final few bytes of the flash file. 2) is also possible. The settings are stored in RAM for use, and only written to flash when required. But a power cycle of the wixel should fix this, rather than a reflash. If the problem persists after a power cycle, then 1 will definitely be the cause of the issue.
The biggest problem here is that everyone is constructing these bridges themselves, using different methods and orientations, etc. If the vast majority have an issue, and I can reproduce it, then I can usually find a software issue and resolve it. But in this case, I simply cannot reproduce the issue with hardware I have on hand. Hence why I strongly believe this is more a hardware related issue than a software one.
If the next time this occurs you can first try a power cycle to resolve the issue. If that does not work, please take a dump of the wixel program into a different file and send it to me. I will then be able to see what state the flash where the settings are stored is like.
Note, ALL settings (hardware type, if it has configured the BLE module, debug messages, LED operations, etc) are written to flash EVERY time. Not just one setting. Flash must be written in Pages, not individual bytes. All settings occupy the last few words of the last page of flash to ensure that writing to them does not corrupt the program in flash. Cheers
On Mon, Feb 20, 2017 at 1:37 PM, WanaGo [email protected] wrote:
Hi John
Sorry but that is not the issue. I hand solder 0402's all the time, these 0603's are large and there is nothing wrong with the soldering. They are rock solid, there is good solder coverage and there are no shorts. I have looked at these under a 20x lens and there is nothing wrong with them at all.
Side note, old square eyes is using standard metal film resistors and has the same exact problem, so I think its safe to say the problem isnt the SMT resistors.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jstevensog/wixel-sdk/issues/24#issuecomment-280974328, or mute the thread https://github.com/notifications/unsubscribe-auth/AIQs89y1Y6FB7ntUlFfF6G4gyYU2xm3gks5rePxwgaJpZM4L3rr9 .
-- John Stevens "You are how you live, not what you have."
Hi old-square-eyes, That looks pretty good. The only thing that may possibly cause an issue is the debris/strands of whatever that are sitting between VALT and P0_0. If that is conductive, or becomes conductive with humidity, you will put the best part of 3.3V onto P0_0, and that will definitely end up recorded as an upper limit of battery voltage. Remember, we are expecting only 1.135V on P0_0 when the VIN is at 4.2V, or fully charged battery. I would suggest cleaning this up. I have had such things cause problems with the serial lines in the past, so it could easily cause an issue with the battery measurement if any amount of conductivity between VALT and P0_0 happens. Cheers
On Tue, Feb 21, 2017 at 10:18 AM, old-square-eyes [email protected] wrote:
[image: dsc_4667] https://cloud.githubusercontent.com/assets/25760491/23144923/ceda0a82-f82f-11e6-98d7-5914ff05ce5e.jpg
Here's mine
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jstevensog/wixel-sdk/issues/24#issuecomment-281204008, or mute the thread https://github.com/notifications/unsubscribe-auth/AIQs84pYBqvjad1YsQgmbcyBsQ-jbVdGks5reh9AgaJpZM4L3rr9 .
-- John Stevens "You are how you live, not what you have."
Just checking in on progress. Very interested in the projects you've mentioned above John.
Well, I am out of a job at the end of this week, so might be able to progress one or two of them. Irony is that I will not be able to purchase any more sensors until I have a new job. So, I will only have this latest sensor to work with. Once it dies, no more xBridge work for a while. But I can move onto the rechargeable board for the transmitters, at least until I have a new job. Cheers
On Mon, May 1, 2017 at 1:13 PM, old-square-eyes [email protected] wrote:
Just checking in on progress. Very interested in the projects you've mentioned above John.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jstevensog/wixel-sdk/issues/24#issuecomment-298279296, or mute the thread https://github.com/notifications/unsubscribe-auth/AIQs87IAcduWM82XK7OScGBrlUEVSqb2ks5r1U3EgaJpZM4L3rr9 .
-- John Stevens "You are how you live, not what you have."
Sorry to hear that. Can I get you offline? I might have some ideas.
Sent a ping on Gitter. Cheers
On Mon, May 1, 2017 at 3:25 PM, old-square-eyes [email protected] wrote:
Sorry to hear that. Can I get you offline? I might have some ideas.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jstevensog/wixel-sdk/issues/24#issuecomment-298288393, or mute the thread https://github.com/notifications/unsubscribe-auth/AIQs81jSv70QfeTfglpgoBgHH7pFVYfaks5r1WzYgaJpZM4L3rr9 .
-- John Stevens "You are how you live, not what you have."