Feature request: Support for rc-thoughts RFID to start charging

thomasekdahlN commented 6 years ago

Love your project, using it on my 4010.

What would really top it off, was to configure all battery charging parameters by reading the rc-thougts RFID, that contains:

Tag ID, Battery Capacity, Cycles-count, C-value and Cellcount https://www.rc-thoughts.com/jeti-rfid-sensor/

Idea:

read RFID tag to set alle chargin parameters for the battery correct (for 1C charge) (Way easier and faster than having to input all the values all the time, find it rather limiting)
bump the Cycle-count on each charge - keeping track of the number of times each battery has been charged
Maybe also add internal resistance data to bump tag if possible.

TheBum commented 6 years ago

It's feasible, but it would be best to eliminate the Arduino and let the Pi do everything. I found this page for interfacing an RC522 RFID reader with a Raspberry Pi that would work alongside the case fan control circuit. I may give it a shot once I finish my other ongoing projects.

https://pimylifeup.com/raspberry-pi-rfid-rc522/

TheBum commented 6 years ago

I have an RC522 RFID reader on order from Amazon. It should arrive tomorrow.

thomasekdahlN commented 6 years ago

Great. Looking forward to the results. I agree (and Tero) on coupling the RFID reader directly to the PI (No Arduino). This will make your solution the very best. I love it.

thomasekdahlN commented 6 years ago

If you need help reading/understanding the tag format, I'm sure Tero will help.

TheBum commented 6 years ago

That's something I'll have to research once I get the reader and the Pi talking with each other. I'll definitely engage Tero. since he's obviously put a lot of work into decoding the data format.

RC-Thoughts commented 6 years ago

I think I have a extra RasPi 3 somewhere, let's have some fun! 👍

TheBum commented 6 years ago

I played around with some code for reading specific blocks using lower level routines; the higher-level routines in the sample code always deal with text in blocks 8-10. When sending the IDLE request at the beginning of the sequence, it returns a TagType value that may or may not be what I need to distinguish between the Revo and generic tags (there's absolutely no documentation with this code). The value it returned for the keychain FOB included with the reader/writer was 0x10, which according to the Arduino library code translates to a MIFARE Plus. I'll probably have to wait for my MIFARE 1K tags to arrive to verify.

I'm designing tag read polling to run in its own thread, under the assumption that the system should be ready to read at all times when not writing a tag or performing an operation on both sides (charge, discharge, etc.). Once the data has been parsed, the system will set a flag that the mobile app can key on during its polls of the Pi to pull the battery parameters across. The mobile app will send a request to reset the flag after it has obtained the parameters (or it can be reset automatically after responding to the parameter request) and then present options of which channel to use and what to do with that pack (charge, discharge, storage charge, balance), maybe in a simple grid of buttons.

When writing a tag or if an operation is being performed on both channels, the read polling will be temporarily halted.

Thoughts? Am I way off base on the interaction between the mobile app and the Pi or any other part of the implementation?

Also, what constitutes a cycle for incrementing the count? Only charges? Storage charges if the battery is discharged below storage voltage?

EDIT: Updated with more conditions on running the read polling thread.

scornflake commented 6 years ago

Yep, a couple off the top of my head:

a) I wonder if we should involve Tero in this conversation? He’s got considerable experience with both Revo and “other” tags and might be able to give us a leg-up in the implementation. Also, I wonder if we could use the same tag layout?

b) When I designed the server/client, one thing that became apparent pretty early on is to have the client being ‘read only’ as much as possible. It makes coding it far easier, and you can always see the server as a “the truth” (you don’t have to worry about syncing stage, so much).

Let me think here… ponder ponder:

So, the tag will have info. I like the idea of a thread on the server, polling for that - that makes sense.
A tag is read, the info goes into the server.
- The server enters a “Begin charge with RFID” state.
- Each subsequent tag causes an ‘accumulation’ of information, e.g: total capacity,
- We could also do verification at this point (don’t allow tags of differing cells)
- The resulting profile would be a mix of # packs and min mAh (so, charge at min mAh X # packs, or choose a preset close to that)
The client sees the ‘Begin charge with RFID’ state, and brings up a UI saying “N packs, max M mAh. Confirm?” (or other UI to allow selection of a preset)
The server kicks off the charge.

At that point, the client will be reading server side state like it does now. i..e: I wrote the client/server so the client would mostly (baring #88) be able to simply read data from the server to show the correct UI. That’s also why you can start a charge (or other op) on the hardware itself, and the client responds mostly OK.

So, I think you’ll real close, just I would look to minimise the back/forth between the server and the client as much as possible.

c) Counting

I’m assuming you want to write the charge count back to the tag.

I’d say go simple to begin with. If a charge is performed and takes longer than some time, then we increment. However; that implies the pack is still near the reader so that we can write the tag, which in my case it wouldn’t be. I might have 8 packs in parallel, strewn across a large desk area.

So, does that then mean we’d need to increment upon touching the tag? That’d work most times for me. It’s rare that I’d be touching a tag to setup a charge profile, and then NOT using that profile.

Another option would be to never write back to the tag, introduce persistence into the server and count the tags there. That’d make incrementing the counter more reliable (we can increment only when the charge is complete, or after a time, or both). But it means you loose the tracking on the tag itself. I don’t like this idea for the amount of work it introduces tho.

— Neil Clayton neil@cloudnine.net.nz

On 1/03/2018, at 5:59 AM, TheBum notifications@github.com wrote:

I played around with some code for reading specific blocks using lower level routines; the higher-level routines in the sample code always deal with text in blocks 8-10. When sending the IDLE request at the beginning of the sequence, it returns a TagType value that may or may not be what I need to distinguish between the Revo and generic tags (there's absolutely no documentation with this code). The value it returned for the keychain FOB included with the reader/writer was 0x10, which according to the Arduino library code translates to a MIFARE Plus. I'll probably have to wait for my MIFARE 1K tags to arrive to verify.

I'm designing tag read polling to run in its own thread, under the assumption that the system should be ready to read at all times when not writing a tag. Once the data has been parsed, the system will set a flag that the mobile app can key on during its polls of the Pi to pull the battery parameters across. The mobile app will send a request to reset the flag after it has obtained the parameters (or it can be reset automatically after responding to the parameter request) and then present an option of what to do with that pack (charge, discharge, storage charge, balance), maybe in a simple grid of buttons.

When writing a tag, the read polling will be temporarily halted.

Thoughts? Am I way off base on the interaction between the mobile app and the Pi or any other part of the implementation?

Also, what constitutes a cycle for incrementing the count? Only charges? Storage charges if the battery is discharged below storage voltage?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/johncclayton/electric/issues/113#issuecomment-369302260, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrWKmiZIobmgdrsV39RxHsjELtWnkS_ks5tZYLTgaJpZM4SJnnr.

TheBum commented 6 years ago

I've been PM'ing Tero on HeliFreak. I looked at the Bump Controller user's manual and there are several parameters in the bump tag and missing from Tero's implementation. He's following this project (see the RC-Thoughts post above), so hopefully he'll get engaged. I'm attempting to remain compatible with Revo and Robbe.

The required but missing tag values are: Chemistry, Charge Rate (Revo has Accurate, Normal, and Fast rates), and Discharge Rate. I'm hoping he knows where these values reside, or at least can find out. Other values are defined (e.g. termination voltages for charge and discharge, measured cell IR, measured capacity) that we may or may not want to support. We apparently cannot write to Revo tags, so the analytical type data (counts, IR, measured capacity) would be limited to the generic tags.

TheBum commented 6 years ago

Another option would be to never write back to the tag, introduce persistence into the server and count the tags there. That’d make incrementing the counter more reliable (we can increment only when the charge is complete, or after a time, or both). But it means you loose the tracking on the tag itself. I don’t like this idea for the amount of work it introduces tho.

We could use a hybrid approach: cache the count on the server and then, on the bump to start the next charge, write the previous count, somehow flagging that it has been written back to the tag in case the user aborts and then re-bumps. That would ensure the pack's tag was a maximum of one cycle behind.

I still think we need to make the initiation confirmation more than a Y/N in case the user wasn't wanting to charge but discharge or storage charge. The prompt would come up at the same time and would still be server-triggered, but just have more options.

RC-Thoughts commented 6 years ago

Regarding when to update cycles or if they are stored on the server. My sensor has an option to add it in flight (after ~30 sec powered) or it can be disabled if it is updated by charger, so it that sense the sensor is ready. However, if it's stored on server it'll be miss-synced at some point, so my point of view is that it should stay on the tag. Hybrid solution is tempting, that would a) ensure cycle counting and b) reflect "true usage" since the cycle would be added after flight before next flight and on top of that c) be stored on the tag. If it's not on the tag it would only worsen the RFID-information for Jeti-users.

Adding more fields as Chemistry, Charge Rate and Discharge Rate is in no sense any issue even if my sensor does not use them, there's plenty of space on the tag for that. Also if user chooses to use Electric/iCharger/RFID-Sensor combo we do not have to think about using same datablocks as others. And we still are not losing compatibility with Robbe and Revo. (What Robbe-compatibility are you thinking of? Are going to control Robbe-chargers too?)

What comes to Revo datablocks, I'll send you an email.

PS: Check this library: https://github.com/paguz/RPi-RFID Better to use with datablocks / bytes.

TheBum commented 6 years ago

(What Robbe-compatibility are you thinking of? Are going to control Robbe-chargers too?)

No, just don't want to break the tags in such a way that the Robbe chargers can't use them.

Regarding the hybrid solution, all you'd have to do to get the counts fully synced is to bump the battery on the sensor and then say "no" to charging before you leave the field. You could even tap them all and say "no" only once if we add logic to update the counts regardless of whether the charger rejects a bump due to a cell count mismatch. If the battery wasn't cycled since the last time the count was written, nothing would be written if you bumped the battery anyway.

Regarding the library you linked to, it's C++: The Pi's native language is Python.

RC-Thoughts commented 6 years ago

Robbe BID code is here.

The memory-layout is copied straight from the commercial BID-chip. It uses a big amount of blocks for little data. Not really wise itself. But even with more values (like chemistry etc) there's room for quite a lot more.

TheBum commented 6 years ago

Making progress on design (I'm really bored at work). I decided that I needed a separate thread for writing too, since it could be a while between initiating the write and bumping the tag. It also allows the write to be easily aborted.

I'll take a look at the Robbe BID code when I get a chance. Any luck locating the rest of the Revo tag information, Tero?

scornflake commented 6 years ago

Tero has provided me some info / code. I’ve asked him if he thinks it is OK to post here (some of it was from Revo). I will likely ask Revo their opinion as well.

— Neil Clayton neil@cloudnine.net.nz

On 2/03/2018, at 1:45 PM, TheBum notifications@github.com wrote:

Making progress on design (I'm really bored at work). I decided that I needed a separate thread for writing too, since it could be a while between initiating the write and bumping the tag. It also allows the write to be easily aborted.

I'll take a look at the Robbe BID code when I get a chance. Any luck locating the rest of the Revo tag information, Tero?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/johncclayton/electric/issues/113#issuecomment-369781970, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrWKmP6RkPcPGXb2SVfFRekwCMwtsFEks5taJYdgaJpZM4SJnnr.

scornflake commented 6 years ago

@TheBum might I suggest a queue rather than multiple threads. You'll likely have more control, and it'll be easier to debug and synchronize access to the hardware.

TheBum commented 6 years ago

It's essentially a state machine: either it's reading (99.9% of the time) or it's writing. I've designed it so that only one thread can run at a time. When a write is requested, the read thread is terminated; the write request is essentially an interrupt of the normal reading behavior. The write thread only runs for as long as it takes to write the tag after requesting it, which includes the time it takes for the user to bump the tag. The read thread won't immediately restart so that the pack can be removed from the sensor after writing without being picked up as a read bump, probably after a user acknowledgment.

TheBum commented 6 years ago

@RC-Thoughts I'm not seeing any of the mappings to blocks 60 and 61 in the BID code that I saw in your code. I'm probably just missing some context, especially since the site is in German and Google Translate doesn't do a perfect job, especially when there are typos. Are you using 60 and 61 because you're sure they won't interfere with the Robbe blocks. If that's the case, am I correct in assuming that I can simply use the blocks above that (62 and whatever others are needed for all the data)?

RC-Thoughts commented 6 years ago

BID uses one or two bytes here, another there, bytes used are "all over the place" but BID does not use blocks 60/61. I do for the reason you guessed, 60/61 is not used in BID, therefore my tags can be "dual-used" as BID-tags also. This was a request from some German users. Since the Robbe BID is also DIY I have no idea of amount of users', would guess pretty low. RCT-sensors are used by few hundreds users to my knowledge based on surveys, sold sensors and forum-traffic on subject.

I can try to get hold of a data-scan of used Robbe BID tag.

And yes, for the chemistry etc for example 62 is usable. (May I suggest numerical form in tag instead of ASCII like "LiPo", this way I could use it too later on?, For example 1=LiPo, 2=LiFe etc. I cannot use text due Telemetry restrictions)

johncclayton commented 6 years ago

Try DeepL instead of Google - it's WAAAAY better at translation. Or ask me

I can give the German stuff a shot.

Thanks,

John Clayton Skype: johncclayton

On 2 March 2018 at 06:44, TheBum notifications@github.com wrote:

@RC-Thoughts https://github.com/rc-thoughts I'm not seeing any of the mappings to blocks 60 and 61 in the BID code that I saw in your code. I'm probably just missing some context, especially since the site is in German and Google Translate doesn't do a perfect job, especially when there are typos.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/johncclayton/electric/issues/113#issuecomment-369826961, or mute the thread https://github.com/notifications/unsubscribe-auth/ABVx0pLqI5VGhowIvSPGIXTfI8acVTwYks5taNw1gaJpZM4SJnnr .

TheBum commented 6 years ago

No real need now. Now that I know Tero used blocks not used by Robbe, then the Robbe format is immaterial.

It does beg the questions:

Why did you only use 8 bytes of the 16 in block 60?
Why didn’t you keep the cycle count instead of the battery C rating in block 61 with the “disable counts” field?

RC-Thoughts commented 6 years ago

Because I didn't know better, RFID was the first sensor I ever made as a total programming-n00b (still am) and RFID-part is for the most part a copy from another project by Alastair as credited in notes. And it have worked for 1.5 years :)
I don't understand, what do you mean? Actually I found a missing write-byte on block 61 when cycle-count is increased when I looked at the code trying to understand the question, is it this you mean? (Corrected now)

EDIT: Correction added

TheBum commented 6 years ago

Understand. I forget that some people are new to big software projects. I've been developing software for 26 years. I work on a project in my job with very quick turnarounds, so I'm used to this seat-of-the-pants style of programming.
I just meant that I thought the stuff that's more or less static would be on one block and the more dynamic stuff (cycle counts and whether or not to increment cycles) would be on the other block. I noticed that cycle counts are in block 60 with the static data and C rating (which is static) is in block 61 with the dynamic data.

TheBum commented 6 years ago

The way I see it, we need to add the following fields to what Tero has defined on the RCT tag:

Maximum charge rate as a C multiple. This is a not-to-exceed value that the bump logic will validate against. This will likely be stored as an unsigned 16-bit integer.
Desired charge rate in mA or a multiple thereof. The main question for this field is whether to make it 16- or 32-bit. If using whole mA, a 16-bit unsigned integer would allow a maximum charge rate of 65.535A, While this might be OK for modern times, it might not stand the test of time. So, the secondary question is: should it be stored in 16 bits with a bit resolution of, say, 10mA, or in 32 bits as a whole number of mA?
Desired discharge rate in mA or a multiple thereof. For consistency, keep the same integer range/resolution as the desired charge rate.

The maximum discharge rate would be the C rating of the pack, which already has a defined field on the RCT tag.

It would be nice to know how the Revo tag stores these values. We may want to follow their lead.

scornflake commented 6 years ago

2) I would have though resolution of 100ma would be fine. When do you really need less than that? Even on a 800mah single cell, that’d give you all the options you’d need, wouldn’t it?

— Neil Clayton neil@cloudnine.net.nz

On 3/03/2018, at 12:57 PM, TheBum notifications@github.com wrote:

The way I see it, we need to add the following fields to what Tero has defined on the RCT tag:

Maximum charge rate as a C multiple. This is a not-to-exceed value that the bump logic will validate against. This will likely be stored as an unsigned 16-bit integer.

Desired charge rate in mA or a multiple thereof. The main question for this field is whether to make it 16- or 32-bit. If using whole mA, a 16-bit unsigned integer would allow a maximum charge rate of 65.535A, While this might be OK for modern times, it might not stand the test of time. So, the secondary question is: should it be stored in 16 bits with a bit resolution of, say, 10mA, or in 32 bits as a whole number of mA?

Desired discharge rate in mA or a multiple thereof. For consistency, keep the same integer range/resolution as the desired charge rate.

The maximum discharge rate would be the C rating of the pack, which already has a defined field on the RCT tag.

It would be nice to know how the Revo tag stores these values. We may want to follow their lead.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/johncclayton/electric/issues/113#issuecomment-370091827, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrWKqlI_ZORDU5VgEW38VmtYjFRz_iRks5tadxhgaJpZM4SJnnr.

TheBum commented 6 years ago

I think 100mA resolution would be reasonable too. Does the iCharger even allow charge or discharge currents at a resolution less than 100mA?

It did get me to thinking about how the capacity is stored on the RCT tags. 20000mAh packs are not uncommon in the drone world and I think the RCT tag format uses whole mAh in a 16-bit number. I could foresee 66000 or larger packs in the near future. The best way around that IMO is to add a version field, maybe in one of the block-60 bytes. If zeros are written to the unused bytes by the Jeti RFID module right now, we could start at version 0. This might be the time to define a version 1 that allows larger capacities than 65535mAh.

scornflake commented 6 years ago

Or just use 32 bit and be done with it! Are we short on bytes?

— Neil Clayton neil@cloudnine.net.nz

On 3/03/2018, at 2:04 PM, TheBum notifications@github.com wrote:

I think 100mA resolution would be reasonable too. Does the iCharger even allow charge or discharge currents at a resolution less than 100mA?

It did get me to thinking about how the capacity is stored on the RCT tags. 20000mAh packs are not uncommon in the drone world and I think the RCT tag format uses whole mAh in a 16-bit number. I could foresee 66000 or larger packs in the near future. The best way around that IMO is to add a version field, maybe in one of the block-60 bytes. If zeros are written to the unused bytes by the Jeti RFID module right now, we could start at version 0. This might be the time to define a version 1 that allows larger capacities than 65535mAh.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/johncclayton/electric/issues/113#issuecomment-370101428, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrWKhCM4XLBTEy7s2xhCGaQ_SZuXiRHks5taewjgaJpZM4SJnnr.

RC-Thoughts commented 6 years ago

I think this is wrong: "The maximum discharge rate would be the C rating of the pack, which already has a defined field on the RCT tag"

65C or 70C batteries are not uncommon, as charge-rate it's way too high. To my knowledge highest charge-rate from manufacturer is 10C for a 60C battery. (These apply to LiPo)

johncclayton commented 6 years ago

Time for me to chip in. No pun intended.

I love the idea of the feature but I would like to point out that I've been made aware (before we started this project) that FMA have in the past taken legal steps to protect their inventions.

Speficially in the area of using an RFID tag.

So while I totally support the concept of RFID being used I would not want this in the main branch of our repo. I would not want the entire project to face some kind of legal issue for one feature.

I suggest that this feature be segregated via either a plug-in or repo fork such that if the case arises that legal steps are taken then the main functionality doesn't have to be pulled out and can still benefit everyone.

I'm totally open to discussing how we might do that.

Thanks

John Clayton CTO

On Mar 3, 2018 06:56, "Tero @RC-Thoughts.com" notifications@github.com wrote:

I think this is wrong: "The maximum discharge rate would be the C rating of the pack, which already has a defined field on the RCT tag"

65C or 70C batteries are not uncommon, as charge-rate it's way too high. To my knowledge highest charge-rate from manufacturer is 10C for a 60C battery. (These apply to LiPo)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/johncclayton/electric/issues/113#issuecomment-370121982, or mute the thread https://github.com/notifications/unsubscribe-auth/ABVx0nObeFSvxYZZ_MTRDZ-XVueSY3lyks5tajCWgaJpZM4SJnnr .

RC-Thoughts commented 6 years ago

I just wrote to Revo and asked it straight out.

TheBum commented 6 years ago

I think this is wrong: "The maximum discharge rate would be the C rating of the pack, which already has a defined field on the RCT tag"

65C or 70C batteries are not uncommon, as charge-rate it's way too high. To my knowledge highest charge-rate from manufacturer is 10C for a 60C battery. (These apply to LiPo)

Note that I’m talking about maximum discharge rate, i.e. the rate at which the pack can be run down, not charged. A 60C 5000mAh pack may only be able to be charged at 25-50A (5C-10C), but it can be discharged at 300A. It may not have a long life if run that hard, but it’s spec’ed for that.

As for legal ramifications, I’m OK with a fork of the server, but there has to be a user interface for the functionality to be useful. You can side-load an app in Android, but not in iOS; the app has to be released to the public except for test flighting, which has a limited lifetime. Should I make it a separate fork from my own? My case fan changes have already been merged into the main, so it’s freed up for RFID changes.

I don’t know how NZ IP law is, but in the US, reverse engineering is legal except for cracking encryption. As long as you’re not stealing their source code or screen layouts, you can do your own implementation that has similar features. You’re not supposed to be able to patent an idea, only the implementation. If we leave support for Revo tags out completely, there’s not much that Revolectrix/FMS can do.

TheBum commented 6 years ago

I have the code working to write and read RCT tags as well as accumulate charge and discharge rates for multiple packs. I have uploaded the files to my fork (rfidtagio.py, test_tag_reader.py, test_tag_writer.py). It still needs more testing, but it's at least 90% stable. I've programmed two tags and tested them with multi-tag reading.

TheBum commented 6 years ago

Is there any way to send instant notifications from the server to the mobile app? If not, I may add a 3-color LED to a couple of GPIO outputs provide an indication that a tag scanned or was rejected (e.g. if it was already scanned in the current parallel set, or the tag hasn't been written to yet).

TheBum commented 6 years ago

I think the server changes are done. The 3-color LED consists of a red LED and a green LED with a common cathode that, when lit at the same time, produce amber. The red LED is connected to GPIO 16 (board pin 36) and the green LED is connected to GPIO20 (board pin 38). The cathode is connected to ground (I used board pin 34 to be able to use a servo connector for the connection). The conventions for the LED indicator are:

Solid green = reader active, ready to accept tag touches.
Solid amber = writer active, waiting for the tag to be touched for writing.
Green flashing (4 times) = tag registered in the tag list. All registered tags must have the same chemistry and cell count.
Amber flashing (4 times) = tag successfully written.
Solid red (2 seconds) when reading = Tag rejected: tag data is not valid, or chemistry or cell count don't match existing tags in the list.
Solid red (2 seconds) when writing = Destination tag was already programmed and the "force" option wasn't specified, or tag writing may have failed (tag couldn't be read after the write attempt).
Off = RFID tasks are idle (no thread running).

There is one case where I'm not sure what to indicate:

When reading, what should be indicated if a tag is touched that had already been registered during the current read session? Options are: stay solid green (no indication), green flashing without adding again to the list, or red to indicate that it cannot be added to the list because it's already there. Maybe a different indication?

TheBum commented 6 years ago

I did a little video demonstrating the operation using Safari and curl. I uploaded it to YouTube as an unlisted video so that it’s not accessible to the general public unless they have the link. I can either post the link here, or send it to interested people via email or IM/PM.

tsteneker commented 6 years ago

I am interested Great stuff you are doing.ThanksTerry -------- Original message --------From: TheBum notifications@github.com Date: 2018-03-11 8:41 PM (GMT-08:00) To: johncclayton/electric electric@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [johncclayton/electric] Feature request: Support for rc-thoughts RFID to start charging (#113) I did a little video demonstrating the operation using Safari and curl. I uploaded it to YouTube as an unlisted video so that it’s not accessible to the general public unless they have the link. I can either post the link here, or send it to interested people via email or IM/PM.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/johncclayton/electric","title":"johncclayton/electric","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/johncclayton/electric"}},"updates":{"snippets":[{"icon":"PERSON","message":"@TheBum in #113: I did a little video demonstrating the operation using Safari and curl. I uploaded it to YouTube as an unlisted video so that it’s not accessible to the general public unless they have the link. I can either post the link here, or send it to interested people via email or IM/PM."}],"action":{"name":"View Issue","url":"https://github.com/johncclayton/electric/issues/113#issuecomment-372185915"}}}

RC-Thoughts commented 6 years ago

@TheBum please send the link, very curious :)

scornflake commented 6 years ago

Im curious too! I’d say, lets post the link here. We’re going for an open implementation, so I don’t see a problem sharing tests / attempts / working variants (unless… I’m missing something super secret special?)

— Neil Clayton neil@cloudnine.net.nz

On 12/03/2018, at 4:41 PM, TheBum notifications@github.com wrote:

I did a little video demonstrating the operation using Safari and curl. I uploaded it to YouTube as an unlisted video so that it’s not accessible to the general public unless they have the link. I can either post the link here, or send it to interested people via email or IM/PM.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/johncclayton/electric/issues/113#issuecomment-372185915, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrWKiWEfQcK_YHUNodwMMoj5bPq8FM1ks5tde5-gaJpZM4SJnnr.

johncclayton commented 6 years ago

Hi Guys

While I'm super being with my day job (and life in general), I'd love the link as well in order to see progress. The ideas here are awesome and I'm glad that the open source model is benefiting more people than we'd otherwise reach. I'm not currently searching the good 'ol net for activity here - are you gents also active on helifreak or something other channel?

Thanks,

John Clayton Skype: johncclayton

On 12 March 2018 at 07:13, Tero @RC-Thoughts.com notifications@github.com wrote:

@TheBum https://github.com/thebum please send the link, very curious :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/johncclayton/electric/issues/113#issuecomment-372203393, or mute the thread https://github.com/notifications/unsubscribe-auth/ABVx0i7fVIIEfBq6mSNLft9zt9AvJfJQks5tdhH7gaJpZM4SJnnr .

TheBum commented 6 years ago

I just wasn’t sure how much attention we wanted to draw from Revo with an actual implementation, in case they have a problem with this. Here’s the link:

https://youtu.be/6x2ptB1sdSo

Some discussion has taken place in Neil’s thread on HeliFreak, but for the same reason I’ve been reluctant to post the video link, I’ve avoided posting anything about it there. We can certainly move the discussion there.

johncclayton commented 6 years ago

WOW on the RFID function, very nicely done!

I think the easiest way is likely just to ask them.

If... no... when this get published they'll find out anyway.

Using a JETI RFID sensor is potentially less risky from a legal point of view as it's not related to charging gear - yet hooking RFID directly to the charger and driving interactions with is maybe/likely/going to raise FMA's eyebrows - if I had a patent on that, it would raise mine. If they do pull something like a cease and desist then what does one do? Does anyone here have contacts with a patent lawyer that could guide a first contact? For example - it could well be that a cease and desist is just hot air designed to scare. For example, if a C&D is delivered - must it be presented alongside a publically visible patent in certain countries? I have no idea, I'm not a patent lawyer but I could easily believe scare tactics would be a sensible first port of call for any business as it's cheap to execute.

So I'd like to know from you guys - do you have any contacts? I'd be willing to fund a small amount of legal expense to investigate an initial C&D attempt by FMA should we get to that point - simply because I don't want to see a community project get killed by scare tactics (IF that's what they are). I'd be interested to talk to you guys about your feelings on that as well - in the first instance via Skype/Discord/Telegram/whatever.

If you're willing - please contact me on Skype and we'll find a time to chat.

Thanks,

John Clayton Skype: johncclayton

On 12 March 2018 at 14:13, TheBum notifications@github.com wrote:

I just wasn’t sure how much attention we wanted to draw from Revo with an actual implementation, in case they have a problem with this. Here’s the link:

https://youtu.be/6x2ptB1sdSo

Some discussion has taken place in Neil’s thread on HeliFreak, but for the same reason I’ve been reluctant to post the video link, I’ve avoided posting anything about it there. We can certainly move the discussion there.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/johncclayton/electric/issues/113#issuecomment-372304866, or mute the thread https://github.com/notifications/unsubscribe-auth/ABVx0u4-ipRlhHAx_KHM1Bdcajo50O5zks5tdnSNgaJpZM4SJnnr .

TheBum commented 6 years ago

As I mentioned earlier, you’d think if their Bump technology were patented, they’d have “patented” or “patent pending” verbiage on their website. I’ve looked extensively and the only patent I’ve found mentioned is for the Copilot II, presumably for the IR technology they use.

I’m going to make a small tweak to the LED indications: if a tag is rejected as part of an ongoing operation (e.g. when reading tags and a chemistry/cell count conflict is encountered), the LED will flash red rather than go solid red. Solid red will be reserved for fault conditions that terminate the current operation (e.g. a tag write fails).

TheBum commented 6 years ago

One last bit of housekeeping: the MFRC522.py module. It's only available in a git repo, i.e. it has no apt-get or pip installer, so how do we go about installing it in the worker docker image? Clone the repo to a temporary location and then do a simple copy of the required file into the image as RUN actions in Dockerfile-worker?

TheBum commented 6 years ago

Just a few notes of things that the mobile app needs to be aware of:

The commands for the RFID reader are all JSON blobs PUT to the rfid/read subpath. They take the following form: { "command":\<command string> }.

Start reading command string: "start reading".
Stop reading command string: "stop reading".
Cycle completed command string: "register cycle".
Kill reading command string: "kill reading".

The return is the current status of the reader in all cases.

The difference between "stop" and "kill" are that "stop" keeps the thread object alive that contains the list of tags so that a GET can be issued to retrieve the list without the possibility of another tag being scanned. "Kill" will destroy the thread object; doing a GET after a kill will always give you an empty tag list and a "dead" status.

The mobile app should not issue a kill until after it notifies the reader that a charge cycle completed (if a cycle didn't complete, an immediate kill is appropriate). That will allow the reader to use the list it already has to figure out which batteries to mark for a cycle increment the next time they're read.

Only two commands are used for the RFID writer:

Start writing the tag with the given parameters. A JSON blob is POSTed in this case with a "rfid_tag" dictionary and an optional "force" parameter that, when present and set true, forces the writer to overwrite the next tag scanned whether of not it has been previously written. Leaving off the "force" parameter or setting it to false will allow the writer to only write the tag if it's blank.
There is no "stop writing" command. Writing will stop automatically after successfully writing a tag or encountering a fatal error while writing. Attempting to write to an already written tag without the "force" parameter is not currently considered a fatal error, so the writer will continue waiting for a valid tag in that case.
Kill writing command of the same context and format as the "kill reading" command, only PUT to rfid/write with a command string of "kill writing".

A status request is also supported as a GET request to rfid/write. The mobile app will have to poll the status to determine when the write completes or aborts.

During a write attempt, the mobile app should always begin with an un-"force"d write. It should then key on a UsedTag response and pop up a "would you like to overwrite" prompt. If the answer is "yes", the mobile app should send a "kill writing" command and then re-issue the write command with the "force" parameter set true.

TheBum commented 6 years ago

Since no RFID tag reading or writing will be initiated without the mobile app sending a command first, I think we could go ahead and merge these changes into the master. Let me know and I'll create a pull request.

EDIT: I'm going to hold off on that until I can add battery cycle tracking. I just realized that I never implemented it.

TheBum commented 6 years ago

Battery cycle tracking is done. You all (or all y'all, in Southern vernacular) may beta test away.

thomasekdahlN commented 6 years ago

Great work. I would love to beta test.

Do you have a component list and wiring diagram for reading the RFID tags?
Which image version is the beta functionality available on?
I'm willing to fund a small amount of legal expense to investigate an initial C&D attempt by FMA - this project is to great to be killed by lawyers;-)

scornflake commented 6 years ago

Hi!

Currently I think ‘thebum’ has a working branch with RFID. I’m intending to try to use my existing RFID boards (no idea if that’ll work yet). They are the same as the smaller green ones found on rc-thoughts.com (for the Jeti RFID reader/writer).

I’ve yet to do anything on the UI. There is server code implemented, and the server side can detect things like a batt being read, can sum up further batts being read (i.e: 5 6s have been seen, suggested C of 3, with max mah 3600). The client doesn’t do anything with this yet. That’s the bit I need to get onto.

Other than that, no idea on the legal side. I know either thebum or (someone?) did email revo directly. I have’t heard of any response yet. Current intention is to write the UI so it’ll work on both branches. So on the ‘master’ it won’t show RFID. On ’thebums’ branch, it will. That way we have options, if required. Also, merging it back to master will be a piece. of. cake.

I like cake.

Off to play with my TDF!

— Neil Clayton neil@cloudnine.net.nz

On 1/04/2018, at 5:42 PM, thomasekdahlN notifications@github.com wrote:

Great work. I would love to beta test.

Do you have a component list and wiring diagram for reading the RFID tags? Which image version is the beta functionality available on? I'm willing to fund a small amount of legal expense to investigate an initial C&D attempt by FMA - this project is to great to be killed by lawyers;-) — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/johncclayton/electric/issues/113#issuecomment-377758765, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrWKgJHPbi_2fLiixOaxdmUKi8d8gs1ks5tkGjKgaJpZM4SJnnr.

johncclayton commented 6 years ago

Reading RFID tags: I'll let somebody more knowledgeable (ThBum?) on that one go for that question.

In terms of legal expense I also don't want to have the project killed. I'm also able to help out a little on the finance side to push a C&D defense. I've looked for their patent and haven't been able to find a version of it online, which I believe doesn't mean it doesn't exist but there I'm not sure - patent lawyer question.

Does anyone on the group have access or contacts with an experienced patent lawyer. I can find some but I'm in Switzerland and these guys cost at least 300 per hour.

-- John

on Sun, Apr 1, 2018, 07:42 thomasekdahlN notifications@github.com wrote:

Great work. I would love to beta test.

Do you have a component list and wiring diagram for reading the RFID tags?

Which image version is the beta functionality available on?

I'm willing to fund a small amount of legal expense to investigate an initial C&D attempt by FMA - this project is to great to be killed by lawyers;-)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/johncclayton/electric/issues/113#issuecomment-377758765, or mute the thread https://github.com/notifications/unsubscribe-auth/ABVx0vGq7mh8EgmqCr6LigX2Bq7OwCN1ks5tkGjKgaJpZM4SJnnr .

TheBum commented 6 years ago

It should work with any RC522 RFID reader/writer. It has to use SPI for communication. I used this one to develop the code:

https://www.amazon.com/dp/B01KFM0XNG

There are multiple resources on the web for connecting it up.

johncclayton / electric