I2C Encoder V2 ALIVE on Kickstarter! - Page 1
Forum section: electronics / general

author: Atika
author_rank: Contributor
timestamp: June 27, 2018, 10:28:10 pm
content: The I2C Encoder is a tiny board that you can read a mechanical rotary encoder on the I2C bus.https://www.kickstarter.com/projects/1351830006/i2c-encoder-v2?ref=t8hzgiThe I2C Encoder V2 supports both standard rotary encoder and the illuminated RGB encoder footprints!There are also 3 configurable GPIOs that are organized with the same footprint of RGB LED. You can use them as PWM, I/O or ADC.it has also 256bytes of EEPROM.At the end of the campaign, we will provide the HW and FW part of the project!

author: larsdenmark
author_rank: Regular Contributor
timestamp: June 28, 2018, 08:12:10 am
content: It looks interesting!A small question: How many bits is the ADC?And then there is some bonus info: Apparently illuminated RGB rotary encoders is a thing! Who knew?

author: BillyD
author_rank: Regular Contributor
timestamp: June 28, 2018, 08:53:11 am
content: Nice little unit. Is there any facility for encoder velocity, or click-able encoders?

author: Atika
author_rank: Contributor
timestamp: June 28, 2018, 09:24:11 am
content: The resolution of the ADC is 8bitBut the PIC ADC is 10bit, it's scaled to 8bit in order to use only 1 register. Of course this part it's possible to modify in the FW.Click-able Encoders are supported, in case of normal encoder or RGB encoder. It's possible also to configure an interrupt when pressed or released.The velocity of rotation is not calculated, the board is intended to be used by human, not motor.Thanks for the info, i will make more clear in the campaign!

author: Kean
author_rank: Unknown
timestamp: June 28, 2018, 12:53:26 pm
content: Velocity support would be really nice. A little tricky to get right, but very useful for some applications where you need to handle a large range of values (you do have 32-bit!) but still have the ability for fine adjustment.

author: Atika
author_rank: Contributor
timestamp: June 28, 2018, 01:08:42 pm
content: What you mean si something like that:For example: if i rotate the encoder slower the increment is by 1, if i rotate a bit fast the increment is by 10 if i rotate more fast the increment is by 100Right?

author: Kean
author_rank: Unknown
timestamp: June 28, 2018, 04:24:30 pm
content: Quote from: Atika on June 28, 2018, 01:08:42 pmExactly! It should probably be an option that can be enabled, not the default.

author: Atika
author_rank: Contributor
timestamp: June 29, 2018, 07:14:57 am
content: Yes looks interesting!I will try to implement as soon as possibleThanks

author: Kean
author_rank: Unknown
timestamp: June 29, 2018, 07:32:54 am
content: I know the hardware is open, and schematics already posted. Do you think the firmware will also be open at some point?

author: Atika
author_rank: Contributor
timestamp: June 29, 2018, 07:56:33 am
content: Of course!Will be publish at the end of the campaign on GitHub here:https://github.com/Fattoresaimon/I2CEncoderV2I also published the FW and the HW of the first version here:https://github.com/Fattoresaimon/i2cencoder

author: Kean
author_rank: Unknown
timestamp: June 29, 2018, 08:12:12 am
content: Great.In that case I'll switch my pledge from 10 to 25. And also grab some of your first version off Tindie.

author: Atika
author_rank: Contributor
timestamp: June 29, 2018, 08:31:13 am
content: Great!Thanks a lot!

author: Atika
author_rank: Contributor
timestamp: June 30, 2018, 10:03:52 am
content: I forgot to write that I2C Encoder V2 is fully founded in 12 hours!We still have 28 days to run. Hoping for the best!Thanks to every one

author: larsdenmark
author_rank: Regular Contributor
timestamp: July 04, 2018, 07:44:46 am
content: I'm backing this project. It should give me encoders to last a lifetime. Now I just need to figure out how the RGB LEDs are going to improve my interface.

author: Atika
author_rank: Contributor
timestamp: July 05, 2018, 02:16:59 pm
content: Thanks larsdenmark !We reach 100 backers!Thanks to every one!

author: PlainName
author_rank: Super Contributor
timestamp: July 05, 2018, 02:35:01 pm
content: I couldn't resist this one either, but I couldn't figure out if it was +4or+6 for the RGB/LED options, or if one needs both. So I added +10 to be safe...Was that the right thing to do, or should I modify my pledge to maximise my options?

author: Atika
author_rank: Contributor
timestamp: July 05, 2018, 02:51:37 pm
content: Thanks dunkemhigh for the pledge!+6 is if you want the illuminated RGB Rotary encoder, the rotary encoder with the illuminated shaft.+4 is if you want a normal encoder (without the illuminated shaft) plus a 5mm RGB LED.With 10€ i will get both the option: 2 RGB rotary encoder and 2 standard rotary encoder. But only two I2C Encoder V2 boards!

author: PlainName
author_rank: Super Contributor
timestamp: July 05, 2018, 03:00:48 pm
content: OK, thanks. I guess that means I need to double the number of boards, then. Should I modify my pledge or do a new pledge for just the boards?

author: Atika
author_rank: Contributor
timestamp: July 05, 2018, 03:16:49 pm
content: If you want to increase the number of boards is more convenient to make a pledge of 5 I2C Encoder V2 boards.There is also the offer to I2C Encoder V2 boards + 5 RGB encoder.If you make 2 different pledge you will pay 2 time the shipping.

author: PlainName
author_rank: Super Contributor
timestamp: July 05, 2018, 04:27:24 pm
content: Ah, good point about the shipping

author: free_electron
author_rank: Super Contributor
timestamp: July 05, 2018, 07:57:39 pm
content: something that i want to see : programmable rollover and lookup tables.for example :---------------limit_low = 22 ,limit_high = 33,rollover = falseint_on_click= trueint_on_change_only = truethe encoder now goes between 22 and 33 , does not roll over , does not underflow. for each 'change' an interrupt is generated. so 32 to 33 generates and int. 33 to 33 does NOT generate an interruptturn right : 22<int>,23<int> ... 31<int>,32<int>,33<int>,33<NO INT! no change>,33<NO INT! no change>,33<NO INT! no change>-----------------------limit_low = 22 ,limit_high = 33,rollover = falseint_on_click= trueint_on_change_only = falsethe encoder now goes between 22 and 33 , does not roll over , does not underflow. for each 'click' an interrupt is generated. so 32 to 33 generates an int. 33 to 33 does also generate an interruptturn right : 22<int>,23<int> ... 31<int>,32<int>,33<int>,33<int>,33<int>,33<int>-----------------------limit_low = 22 ,limit_high = 33,rollover = trueint_on_click= trueint_on_change_only = falseturn right : 22<int>,23<int> ... 31<int>,32<int>,33<int>,22<int>,23<int> .... : the encoder now rolls over properly.other settingslimit_low (16 bit) : lower value of the encoder <nonvolatile>limit_up (16 bit) : upper value of the encoder <nonvolatile>rollover : boolean : stops at limit or rolls over <nonvolatile>int_on_click : boolean : interrupt for every click. <nonvolatile>int_on_change_only : boolean : only interrupts if a change in value is detected works together with int_on_click <nonvolatile>power_on_value : nonvolatile value. this is the value applied at power-up. this allows for example to default an encoder to midpoint. <nonvolatile>use_lookup : boolean : use a lookup table ( max 1 byte ) <nonvolatile>table <bytes> : lookup table <nonvolatile>current_value : current pointer value <volatile, restore from power_on_value>current_data : current data in the table returns table<current_pointer>read_pointer : a byte telling me what the next data byte will be. <volatile, starts at 0 after power_on>auto_increment_read_pointer = boolean : this allows me to stop the readpointer. <nonvolatile>so , for example if i want to make a encoder that can cycle the letter and numbers i can give it a table containing only those ascii codes.0 = 65 ( capital a )1 = 66 ...25 = 90 (Z)26 = 48 (0)36 = 57 (9)table 65,66,67,68,69,70,41,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,48,49,50,51,52,53,54,55,56,57rollover= truelimit_low = 0limit_high=36int_on_change=trueint_on_click=truepower_up = 26if i now turn the scrollwheel i get an interrupt on every change. i can directly read the pointer , or the table.i would change the memory map.current_value should be stored at 0x00current_data should be stored at 0x04and use little endian format. ( least significant byte first)this limits the amount of data i need to stream over i2c.for example : i am only interested in the table lookup, and i know i only use 1 byte , not all 4):i set current_read_pointer to 0x04i set _auto_increment to falsei2c_read always returns me the data pointed at. i don't need to stream all subdata.if i only use 1 byte of the word i dont need to perform 3 useless data transfers.

author: free_electron
author_rank: Super Contributor
timestamp: July 05, 2018, 08:34:23 pm
content: so :register 0x04 : bit 6 : could implement the 'int_on_click' function. called IRTURNif is set IRINC , IRDEC and IRCLICK i will get an interrupt on INCrease, DECREASE or TURNWRAPE=FALSEIRINC=TRUEIRDEC=TRUEIRCLICK=TRUE31<int becasue INCR>,32<int becasue INCR>,33<int becasue INCR>,33<int because IRCLICK, but no roll WRAPE=false>,33<int because IRCLICK, but no roll WRAPE=false>needed :read_pointer : <byte> tells my what location will be read.readmode : [fixed , inframe, autoincrement]for examplei2c_write(encoderi2c,readpointer,0x04)i2c_write(encoderi2c,readmode,fixed)i2cread (4) : give me 4 bytes. the bytes will be addresses 0x04,0x04,0x04,0x04 . the read pointer does not increment during the read. so i can stream data from 1 register. for example the adc input. if i need 16 samples i simply read 16 bytes.i2c_write(encoderi2c,readpointer,0x04)i2c_write(encoderi2c,readmode,inframe)if i read nowi2cread(4) gives me the contents of 0x04,0x05,0x06,0x07 : the read_pointer increments UNTIL a STOP on i2c is received. at that point the read_pointer goes back to its initial settings.so another read gives me again 0x04,0x05,0x06,0x07This way i can limit the amount of i2c transactions. once the device is programmed , i lock down the 'startaddress' of the read and i get immediately what i need . if i only need 1 byte i read one byte , if i need 2 , i read 2.------i2c_write(encoderi2c,readmode,autoincrement)i2cread(4) gives me again 0x04,0x05,0x06,0x07. since autoincrement is on , the readpointer does not reset.so another i2cread(4) now gices me 0x08 0x09 0x0a 0x0b and so on...

author: free_electron
author_rank: Super Contributor
timestamp: July 05, 2018, 08:45:39 pm
content: i just backed for 10 kits including rgb encoder

author: Atika
author_rank: Contributor
timestamp: July 06, 2018, 08:40:31 pm
content: Quote from: free_electron on July 05, 2018, 08:45:39 pmThanks for your pledge!If i have understood correctly your example, the rollover part is already implemented even in the first version of the I2C Encoder.About the lookup table, it is a nice idea, i will think about it.Anyway you don't need to read all the 4 bytes of the 32bits registers, you can read only the byte that you need.

author: free_electron
author_rank: Super Contributor
timestamp: July 06, 2018, 08:49:03 pm
content: i still want the ability to generate an interrupt on every click ( even if no wraparound occurs. )I looked at the sample i2c code and that is a bit 'heavy' on the transactions.If i want to read 4 times the adc register i have 4 accesses in write, four transmissions o fthe required register address four restarts , and four reads and four stops.i want to be able to circularly read without restarts and bus freeing.to read 4 times register 9 what your code does is<start><device_address_in_write><register number 9><restart><device_address_in_read><read_8><stop><start><device_address_in_write><register number 9><restart><device_address_in_read><read_8><stop><start><device_address_in_write><register number 9><restart><device_address_in_read><read_8><stop><start><device_address_in_write><register number 9><restart><device_address_in_read><read_8><stop>This is wasting a massive amount of bus bandwidth.what i want to do is<start><device_address_in_write><readpointer><pointer_value 09><pointer_mode_no_increment><restart><read_8><read_8><read_8><read_8><stop>readpointer is the address of the register holding the pointer for read operations.next is pointer_mode register. that can have 4 settings : direct , no_increment , reset_after_stop, rollover.So. if i do:-------------------------------------------------scenario 1 : reading same register over and over.<start><device_address_in_write><read_mode><no_increment> <stop> : set the read mode to no_increment. i will always be reading the same register.<start><device_address_in_write><readpointer><0x10> <stop> : i tell the device my next read will come from location 0x10.but since readpointer is followed by read_mode in the memory map i can send this in one transaction.<start><device_address_in_write><readpointer><0x10><no_increment> <stop><start><device_address_in_read><read_8><read_8><read_8><stop> . gives me 3 times the contents of register 0x10-------------------------------------------------case 2: reset_after_stop<start><device_address_in_write><readpointer><0x10><reset_after_stop> <stop><start><device_address_in_read><read_8><read_8><read_8><stop> . gives me the contents of register 0x10 , 0x11 and 0x12if i do this again<start><device_address_in_read><read_8><read_8><read_8><stop> i get again the contents of 0x10 0x11 0x12.in other words : the read location starts at <0x10> and increments as long as i request a byte. when a STOP or RESTART is received the readpointer goes back to 0x10 so the next read operation gets that again<start><device_address_in_read><read_8><read_8><read_8><restart><device_address_in_read><read_8><read_8><read_8><stop>gives me 0x10 0x11 0x12 0x10 0x11 0x12-------------------------------------------------case 3 :rollover operation<start><device_address_in_write><readpointer><0x10><normal> <stop><start><device_address_in_read><read_8><read_8><read_8><restart><device_address_in_read><read_8><read_8><read_8><stop>gives me 0x10 0x11 0x12 0x13 0x14 0x15. the STOP or RESTART does not reset the pointer.------------------------------------------------case 4 : directthis works as normal.Normal operation is not affected by this. the other write operations work just as intended.i can do this<start><device_address_in_write><0x05><restart><device_address_in_read><read_8><read_8> . this will give me contents of registers 0x05 and 0x06 (ESTATUS and GPSTATUS)<start><device_address_in_write><0x1D><0xA><no_increment> ' set the readpointer ( register 0x1D > to 0XA ( the LSB of CVAL ) and register 0x1E (read_mode) to and do not increment.<start><device_address_in_read><read_8> <stop> gives me LSB of CVAL.a while later :<start><device_address_in_read><read_8> <stop> gives me the LSB of CVAL. i do not need to readdress the device in write to set the target register. it already knows.2nd scenario<start><device_address_in_write><0x1D><0x7><reset_after_stop> <stop> ' set the readpointer ( register 0x1D > to 0X07 ( the MSB of CVAL ) and register 0x1E (read_mode) to 'reset_after_stop'.<start><device_address_in_read><read_8> <read_8><read_8><read_8><Stop> gives me the entire 32 bit of CVAL<start><device_address_in_read><read_8> <read_8><read_8><read_8><Stop> gives me the entire 32 bit of CVAL again. no need to readdress if i have to read 9 of theseon_i2c_interrupt :{ for (int encoder = 1;encoder <10; encoder ++){<start><device_address_in_read><read_8> <read_8><read_8><read_8><Stop>}}this make my scan very fast on the bus. addressing a device clears the interrupt pini don't need to reprogram my target read address---------------------in short :add registers 0x1D and 0x1E to the register map.0x1D : readpointer 1 byte0x1E : readmode 1 byte.Logic :Code:on_interrupt (event)case state :waitforstart : if event = startevent then state= startedstarted : if event = stopevent then state = waitforstartif event = receivedbyte then{if byte = myaddress_write then state = addressed_in_writeif byte = myaddress_read then state = addressed_in_readif byte = general_call .....if byte = reset .....}addressed_in_write:case(event)receivedbyte : if(first_byte)then {pointer = received_datafirstbyte = false}else {memory(pointer) = received_datapointer ++}stop : firstbyte = true; state = waitforstartrestart : firstbyte = true; state = started;getack : give_ack......addressed_in_read:case (readmode)normal:case (event)get_byte: {sendbyte (memory(pointer))pointer++}restart : state = started;stop : state = waitforstart;giveack : get_ack;no_increment:case(event)get_byte: {sendbyte memory(readpointer) // we send based on readpointer, always the same}restart : state = started;stop : state = waitforstart;giveack : get_ack;reset_after_stop:case (event)get_byte: { if (firstbyte) then {pointer = readpointer ; firstbyte= false} // assign pointer here so that intermediate write do not change beginpointsendbyte memory(pointer)pointer++}restart : firstbyte = true ; state = started;stop : firstbyte = true ; state = waitforstart;

author: Atika
author_rank: Contributor
timestamp: July 06, 2018, 09:08:52 pm
content: Check the datasheet:https://github.com/Fattoresaimon/I2CEncoderV2/blob/master/EncoderI2CV2_v1.0.pdfQuote from: free_electron on July 06, 2018, 08:49:03 pmYes there is!There are the bits IRINC and IRDEC from the register 0x04. They are setted at every time the CVAL register change value, that means at every click.You have also the information about direction.Quote from: free_electron on July 06, 2018, 08:49:03 pmFor example, if you check the chapter 2.4.1 of the datasheet, there is the Counter Value register map.The 4th byte has the address 0x07, the 3th has the address 0x08, and so on.And of course you can read or write those registers.

author: free_electron
author_rank: Super Contributor
timestamp: July 07, 2018, 03:23:12 pm
content: Quote from: Atika on July 06, 2018, 09:08:52 pmThat only happens on CHANGE. I also want interrupt capability if the rotary encoder is turned WITHOUT change.Let's say the encoder is set up to travel between CMAX and CMIN.The interrupt only happens as long as there is change. What if i am at CMAX and i turn to increment ? CVAL does not change.so i would use bit 6 of 0x04 to do an interrupt_on_turn. doesn't matter if we hit the limit or not.I looked at the read code in your arduino driver. it is very heavy on bus transactions i want to slimline that. i have many many devices on the i2c bus and want to limit the amount of data streaming.Will the sourcecode be published for this thing ? then i can add the functions myself.

author: Atika
author_rank: Contributor
timestamp: July 07, 2018, 07:18:40 pm
content: Quote from: free_electron on July 07, 2018, 03:23:12 pmIt'is not correct, in this case even if CVAL does not change the interrupt is still generated. Thanks, i will make more clear in the datasheet.Quote from: free_electron on July 07, 2018, 03:23:12 pmFor reading the CVAL i have made 3 functions where it is possible to read 8 bit, 16bit or 32 bit of data. You don't need to read all of the 4 byte.Quote from: free_electron on July 07, 2018, 03:23:12 pmYes i will release the FW at the end of the campaign. If you want you can have a look on the FW of the first version, they are similar

author: larsdenmark
author_rank: Regular Contributor
timestamp: July 09, 2018, 10:54:45 am
content: How about knobs? Will I need transparent knobs for the RGB encoders in order to see the light?If so, are there any you can recommend?

author: Atika
author_rank: Contributor
timestamp: July 09, 2018, 01:04:33 pm
content: Quote from: larsdenmark on July 09, 2018, 10:54:45 amWe are working to find a nice knob to add. We will add a stretch goal to reach in order to give free knobs to the backers who got the RGB Encoder from our kickstarter campaign.Anyway you don't need the knob to see the light, it is the shaft that became illuminate and this is part of the RGB encoder.

author: PlainName
author_rank: Super Contributor
timestamp: July 09, 2018, 04:35:19 pm
content: Perhaps worse case is one drills a nice 1/4" hole through the middle of a normal knob and push on until the shaft is flush with the top. Acually, done well that could look quite nice

author: Atika
author_rank: Contributor
timestamp: July 09, 2018, 04:43:49 pm
content: Quote from: dunkemhigh on July 09, 2018, 04:35:19 pmNice ideai will think about it

author: Atika
author_rank: Contributor
timestamp: July 10, 2018, 09:17:19 am
content: We have made a small improvement on the HW part.By connecting the address jumpers in a matrix way, i got an extra GPIO and i have used as GP3 instead of using the RED color of the RGB Encoder.In this way, even with the RGB encoder and the normal rotary encoder it is possible to use all of the 3 GP pins.We are also working to find a suitable transparent knob for the RGB Encoder.Most probably we will add a stretch goal to give to the baker a free knob.

author: tsman
author_rank: Frequent Contributor
timestamp: July 10, 2018, 11:40:46 am
content: Quote from: Atika on July 10, 2018, 09:17:19 amIsn't this arrangement going to cause problems? You need diodes to stop it all interfering with each other. If you join A0, A4 and A1 then the PIC will also think A5 is shorted.

author: Atika
author_rank: Contributor
timestamp: July 10, 2018, 12:06:47 pm
content: Quote from: tsman on July 10, 2018, 11:40:46 amUh you are right! what a stupid mistakeSeems it is not possible to do without adding external components.Thanks a lot

author: free_electron
author_rank: Super Contributor
timestamp: July 10, 2018, 07:17:18 pm
content: TRY THIS

author: Atika
author_rank: Contributor
timestamp: July 10, 2018, 07:28:19 pm
content: Nice idea!But like this i'm using 8 GPIO for reading 7 jumpers, and i don't have to much space on the board for extra components.

author: free_electron
author_rank: Super Contributor
timestamp: July 10, 2018, 07:50:53 pm
content: the two diodes are size of an 0402.

author: Atika
author_rank: Contributor
timestamp: July 14, 2018, 07:17:14 am
content: Ohh.. Dave received our package to his mailbag!Hoping a review from himhttps://twitter.com/eevblog/status/1017949724882583552

author: Atika
author_rank: Contributor
timestamp: July 18, 2018, 11:19:47 am
content: We have added a stretch goal to our campaign.If we reach 10000€, we will add for FREE transparent knobs to the RGB Encoders to everyone.Check out the update:https://www.kickstarter.com/projects/1351830006/i2c-encoder-v2/posts/2234400Thanks

author: agehall
author_rank: Frequent Contributor
timestamp: July 18, 2018, 11:48:06 am
content: Hmm, how have I missed this thread previously?? This is just what I need in my parts bin for various projects...

author: glarsson
author_rank: Frequent Contributor
timestamp: July 18, 2018, 12:10:31 pm
content: Will the transparent knob still have the white index mark? I have found it difficult to find nice knobs without useless indexing marks for use on rotary encoders.

author: Atika
author_rank: Contributor
timestamp: July 19, 2018, 12:17:42 pm
content: Here we are with another Update!https://www.kickstarter.com/projects/1351830006/i2c-encoder-v2/posts/2241124Quote from: glarsson on July 18, 2018, 12:10:31 pmI have asked about that, and i'm waiting for the answer. Most probably they can't remove without extra tooling cost.

author: free_electron
author_rank: Super Contributor
timestamp: July 20, 2018, 10:03:13 pm
content: https://www.sparkfun.com/products/10597http://www.hobbytronics.co.uk/clear-knob

author: Atika
author_rank: Contributor
timestamp: July 22, 2018, 01:06:43 pm
content: Quote from: free_electron on July 20, 2018, 10:03:13 pmAlso these knobs have the indicator line. It's made by the company TOP-UP.About the knob that i have choosen, they will make with the indicator line sinked in the plastic but not painted.

author: Kean
author_rank: Unknown
timestamp: July 23, 2018, 07:35:53 am
content: Quote from: free_electron on July 20, 2018, 10:03:13 pmYes, those knobs are OK, and I've been using them. But I don't think they are ideal especially if you want to have several encoders close together on a panel. And I don't like the way the light appears.I suggested this other skirted style to Simone as they are popular in audio panels, and I think it was also the style he prefered. You can obviously still get various alternatives if you want something bigger.The other thing I don't like abouth the transparent knobs is that they don't diffuse the light source. For a single encoder, I like a larger diameter. I just got some of these, and they work pretty well although they are not that bright. I they look great in lower lighting conditions. The pointer is a notch unfortunately, so can't be painted over - but it is pretty tiny.https://www.aliexpress.com/item/5pcs-Translucent-knob-Middle-transparent-25-15MM-encoder-potentiometer-cap-with-half-axis-with-flower-core/32874421565.htmlYou can also use any knob with a white insert, but again they will be reasonably dim. Photo attached showing some examples of the three. All are running off 5V through 120 ohm resistors, so not identical currents for each colour (red is brightest).Simone has sent me a few samples of the new boards, and the latest firmware, for testing/review. The PCBs look great - quite a bit smaller than his earlier design. I am hoping that MickMake or I can get a short review video up before the campaign ends, but we are both swamped with work this week. Dave also has some... but he may also be a bit short on time to get another mailbag video out before the campaign ends.

author: Atika
author_rank: Contributor
timestamp: July 26, 2018, 06:21:03 pm
content: Thanks Kean for your tests with knobs. With the knobs RGB Encoder looks cool!Deadline is approaching. First of all, thanks to everyone who has been helping us to make this project alive successfully!Today we bought the components for this project!We found that the PIC16F18344 is not available on Microchip until October.But we bought the PIC16F18345, it has more RAM and flash memory.Hopefully we will reach the stretch goal in time for giving the free knob

author: timgiles
author_rank: Regular Contributor
timestamp: July 26, 2018, 07:28:40 pm
content: Looks like the target has now been reached :-)

author: Atika
author_rank: Contributor
timestamp: July 26, 2018, 07:34:02 pm
content: Quote from: timgiles on July 26, 2018, 07:28:40 pmMmmm.... not yet, 50€ is missing

author: Kean
author_rank: Unknown
timestamp: July 27, 2018, 02:10:26 pm
content: We didn't have time to do a proper review, but Mick and I were able to include a quick snippet of the I2C encoder in a video this week

author: Atika
author_rank: Contributor
timestamp: July 27, 2018, 05:27:29 pm
content: Quote from: Kean on July 27, 2018, 02:10:26 pmThank you so much!We reach our stretch goal!It means that we will add the transparent knob as a gift to the bakers who choose RGB Encoder.

author: Atika
author_rank: Contributor
timestamp: July 30, 2018, 11:59:04 am
content: The campaign finished successfully!Thank you all!Also Dave did a review on it in his last mailbag. Thanks to Davehttps://youtu.be/e4lIkonz7Rw?t=1h2m42s

author: PlainName
author_rank: Super Contributor
timestamp: July 30, 2018, 03:20:15 pm
content: Well done on having this meet expectations.A thought just occurred to me: I've assumed one has to talk to these via I2C to get any use, but could they be programmed to operate standalone? That is, they output rotary code just like a real rotary encoder, or an analogue voltage just like a digit pot might do?

author: PlainName
author_rank: Super Contributor
timestamp: December 18, 2018, 09:31:18 pm
content: My pledge just arrived and looks fab. By a stroke of luck, I think I've just manufactured a problem for which this would be a solution, too

author: Atika
author_rank: Contributor
timestamp: December 19, 2018, 10:21:04 am
content: Quote from: dunkemhigh on December 18, 2018, 09:31:18 pmThat is great!Hope you'll enjoy the project

author: Mr. Scram
author_rank: Super Contributor
timestamp: December 19, 2018, 10:27:48 am
content: I think not using that fairly horrible font any longer is a good improvement.

author: Atika
author_rank: Contributor
timestamp: January 27, 2019, 10:14:49 am
content: Few monthes ago, we sent our project to Sparkfun to add in their store, no responce from them. And now we have just found out that Sparkfun have made a similar product to our I2C Encoder V2https://www.sparkfun.com/products/15083But it's cost almost 4 times more with less features