**** BEGIN LOGGING AT Thu Sep 27 02:59:57 2012 **** ENDING LOGGING AT Thu Sep 27 08:14:33 2012 **** BEGIN LOGGING AT Thu Sep 27 08:16:20 2012 Sep 27 08:55:17 so where is maemo for raspberry pi? Sep 27 08:59:02 GGon: never? Sep 27 08:59:13 heh Sep 27 08:59:18 meego? :-P Sep 27 08:59:22 RPi isn't a Nokia product, and Nokia's abandoned Maemo anyway Sep 27 08:59:50 then port cssu to it :-P Sep 27 08:59:53 heh Sep 27 08:59:58 … Sep 27 09:00:07 GGon: you realize cssu/maemo/etc is not open source? Sep 27 09:00:23 oh. thought cssu was Sep 27 09:01:05 i was honestly joking anyways Sep 27 09:05:33 why the hell does nokia make both the n9 and the lumia 920? Sep 27 09:05:41 Why do they stretch themselves like that??? Sep 27 09:06:50 what? Sep 27 09:06:54 n9 is old phone Sep 27 09:07:18 Yeah, not that old - and if they keep flip flopping with OSs all of the time they'll never gain any momentum Sep 27 09:08:03 internetishard: Nokia has abandoned all Linux Sep 27 09:09:05 wtf was n9? A test? Old parts that they wanted to get rid of? :P Sep 27 09:09:38 contract Sep 27 09:10:05 afaik Nokia's agreement with Intel(?) said they had to make at least one phone with MeeGo Sep 27 09:10:59 nice way to waste potential. If it's like "fuck it guys, we gotta do this cause a paper says it" - why not try something ambitious and different? Sep 27 09:11:23 Take an interesting risk Sep 27 09:11:39 it's a company Sep 27 09:12:00 yeah yeah... Sep 27 09:14:29 internetishard: because microsoft had experience on phone market Sep 27 09:14:35 internetishard: and mobile OS market Sep 27 09:14:47 internetishard: in the end, their platform once had almost 100% of the market Sep 27 09:14:57 internetishard: so microsoft was much better option Sep 27 09:17:57 It's going to be interesting to see a microsoft product that is more open than an apple product Sep 27 09:18:25 Or maybe less of a walled garden Sep 27 09:18:52 … Sep 27 09:18:58 Microsoft has *always* been more open than Apple Sep 27 09:19:39 Really? Maybe I've been Linux exclusive for too long... :X Sep 27 09:19:44 yes Sep 27 09:19:56 Microsoft made software and didn't care what hardware you ran it on Sep 27 09:20:10 Apple was always "you run our software on our hardware, period" Sep 27 09:20:47 I was thinking more in terms of DRM and file management... Sep 27 10:33:27 'open' is not the word Sep 27 10:33:32 'indifferent' is a better word Sep 27 10:34:28 MS just followed where MS thought the money was Sep 27 10:34:31 open to hardware does not mean hackable... Sep 27 10:34:46 internetishard: microsoft never cared about drm really Sep 27 10:35:02 internetishard: it was just doing what industry wanted Sep 27 10:35:06 and they wanted drm Sep 27 10:35:12 so microsoft gave them that Sep 27 10:35:38 + parts of windows are open source Sep 27 10:35:46 .net is fully open source Sep 27 10:35:59 jacekowski: what about trying to get hardware manufacturer to build drm hardware and stuff? Sep 27 10:36:13 like what/ Sep 27 10:36:15 TPM? Sep 27 10:36:56 ill go completely off-topic and ask if there's any System Shock 2 / Thief 2 fans here Sep 27 10:36:57 TPM was never meant for drm Sep 27 10:37:01 since there's quite good news! :) Sep 27 10:37:08 it was an option Sep 27 10:37:17 but everyone knew that it's not going to work Sep 27 10:38:20 Lava_Croft: yes Sep 27 10:38:28 deepy: http://www.ttlg.com/forums/showthread.php?t=140085 Sep 27 10:38:39 Some patch come out of nowhere, on some French forum Sep 27 10:38:58 It's a huge update to both the Dark engine and its editor, DromEd Sep 27 10:39:08 It's just such big and lovely news that i have to spam it anywhere i can :P Sep 27 10:39:50 AIs now breathe from their head instead of their stomachs. They will no longer drown when up to their waist in water. Sep 27 10:39:59 ;) Sep 27 10:40:02 never noticed? :) Sep 27 10:40:52 that changelog is far from incomplete:) Sep 27 10:40:55 er Sep 27 10:40:56 complete* Sep 27 10:42:35 lol Sep 27 10:52:21 I'm more of a 'darnit!' Sep 27 13:23:02 freemangordon: isn't the flashplayer 10 a joke? Sep 27 13:30:53 Hey, anyone, is Flash 10 for N900 truly released? Sep 27 13:47:15 int_ua: it is Sep 27 13:48:00 kerio: why no official source then? Sep 27 13:48:09 because it was somewhat leaked Sep 27 13:48:13 from the "unreleased" ovi repo Sep 27 13:59:49 freemangordon, DocScrutinizer05, see this: http://www.spinics.net/lists/lm-sensors/msg32275.html Sep 27 14:00:18 maybe n900 has similar temperature formula Sep 27 14:00:37 Degree Celcius = 1 / (t1 + 1/298)- 273 Sep 27 14:00:38 where t1 = (1/B)* ln(( ADCval * 2.5)/(R25*ITBAT*255)) Sep 27 14:00:50 Default values of R25, B, ITBAT are 10e3, 3380 and 50e-6 respectively Sep 27 14:19:58 bme tell me: 0x64 0x00 0x34 0x0d 0x2a 0x01 and 0x0D34 is 3380 Sep 27 14:20:11 from cal data Sep 27 14:22:12 and 0x012A is 298 Sep 27 14:23:03 why is in above patch "1/298" and default value for B=3380?? Sep 27 14:24:09 0x0063 is 100 Sep 27 14:24:18 *0x0064 Sep 27 14:25:17 endianess and shit Sep 27 14:29:06 jacekowski, yes, it is similar Sep 27 14:29:30 I think that bme does not send me random data Sep 27 14:29:45 and also not random in cal Sep 27 14:30:10 nokia used similar formula as in above patch Sep 27 14:54:15 look also: https://lkml.org/lkml/2011/6/28/190 "TBAT look-up table" Sep 27 15:03:32 fakeroot: preload library `libfakeroot-sysv.so' not found, aborting. Sep 27 15:03:51 scratchbox on debian 64bit Sep 27 15:04:39 Now, finally I have temperature formula for n900!!! 1 / ( (1/3380) * ln((RAW*2.5)/(100*0.0067*255)) + 1/298 ) Sep 27 15:04:55 any solutions for fakeroot ? :/ Sep 27 15:05:10 tested on values from DocScrutinizer05 and is correct! Sep 27 15:05:16 freemangordon, see ^^^ Sep 27 15:06:33 formula is same as in patch https://lkml.org/lkml/2011/6/28/190 with B=3380 R25=100 ITBAT=0.0067 Sep 27 15:07:07 in cal data (and also from bme) I got 3 numbers: 3380, 100 and 298 Sep 27 15:07:41 ITBAT was calculated from DocScrutinizer data Sep 27 15:17:11 note that in mtd1 cal in section bme is this line: 05 03 03 00 64 00 34 0D 2A 01 00 00 00 00 00 00 Sep 27 15:25:47 ping merlin1991 Sep 27 15:25:55 Pali: pong Sep 27 15:25:57 you had problems with u-boot Sep 27 15:26:00 yes Sep 27 15:26:20 did you tried to run rescueos from u-boot on that n900? Sep 27 15:26:22 DocScrutinizer05: today after removing and putting back the battery i still had the phantom ACT_DEAD mode Sep 27 15:26:24 ;_; Sep 27 15:26:47 Pali: yeah, though I don't have the data anymore, but I can grab it for you later today Sep 27 15:26:59 ok Sep 27 15:27:23 I need output of dumpatags from rescue os Sep 27 15:27:41 if n900 uboot can boot rescue os... Sep 27 16:14:14 <_PanzerSajt> Hy! I have read the post about this new flash version. They claim that this is really flash10. I could agree with them on this topic, but my question is it has HW acceleration? Sep 27 16:18:46 only one I know of is couple years old "demo" from TI, that doesn't quite work Sep 27 16:19:13 <_PanzerSajt> ShadowJK, yes I have seen that demo too Sep 27 16:19:41 dont know of anything else, besides adobe having withdrawn flash from android Sep 27 16:21:16 http://www.h-online.com/security/news/item/Android-smartphones-USSD-calls-can-kill-SIM-cards-1719230.html <-- fun Sep 27 17:03:16 ah fuck Sep 27 17:03:19 my phonet is been crashing Sep 27 17:03:23 *has Sep 27 17:04:49 this is not good Sep 27 17:05:50 DocScrutinizer05: halp Sep 27 17:09:02 odd Sep 27 17:09:07 crashing how? Sep 27 17:11:26 SpeedEvil: i open the powerkey menu, "TabletPC mode" isn't there Sep 27 17:12:46 i'm just worried this is a precursor for the rapuyama problem Sep 27 17:14:55 odd Sep 27 17:18:10 i know Sep 27 17:18:12 it happened this morning Sep 27 17:18:38 i saw the "no sim" logo flash Sep 27 17:18:59 ~n900-full-reset Sep 27 17:19:00 extra, extra, read all about it, n900-full-reset is when the user presses the PWRON (power-on) button for 8 seconds and removes the battery in the next 8 seconds, the TPS65950 enters NO SUPPLY state instead of BACKUP state, even if a valid backup battery is present. In such a situation, the backup domain registers are also reset, along with the VRRTC domain registers. Sep 27 17:50:55 Pali: coool! Sep 27 17:51:48 :-) Sep 27 17:53:05 last missing is correct BSI value Sep 27 17:57:41 well, I really hope somebody with a DMM and a 'new' BL5J can probe the resistance of BSI Sep 27 18:04:06 in bmeipc is also message for raw bsi value & message for calibration data Sep 27 18:04:24 I will try to write program which ask it from bme Sep 27 18:05:26 new? Sep 27 18:05:33 by does age matter Sep 27 18:05:36 why Sep 27 18:06:54 new model Sep 27 18:09:10 new table is here: https://gitorious.org/rx51-bme-replacement/rx51_battery/commit/4b81bc418e9a1d2d224325c34bd58412b97a377d Sep 27 18:09:19 temperature between 201.81 C and -20.02 C Sep 27 18:09:26 DocScrutinizer05, see ^^ Sep 27 18:09:57 it is enought? Sep 27 18:10:10 nope, we need at very least -25°C Sep 27 18:10:39 iirc Sep 27 18:10:52 do it -35 Sep 27 18:11:07 (finlamd, you know :) ) Sep 27 18:11:12 then table will be too big Sep 27 18:11:13 finland even Sep 27 18:11:15 my freezer hits< -45 Sep 27 18:11:28 Pali: how big? Sep 27 18:11:42 now we have 512 values Sep 27 18:11:56 201.81 deg?!? Pali, WTF? :D:D:D Sep 27 18:12:10 for raw value 1 Sep 27 18:12:28 well, IIRC it is 10 bit ADC Sep 27 18:13:20 so 1024 values? Sep 27 18:13:46 yes Sep 27 18:14:03 ok Sep 27 18:14:03 but based on 1024 values, we can interpolate Sep 27 18:14:17 (but don;t tell doc) Sep 27 18:14:36 so max (raw) adc value is 1024 Sep 27 18:14:44 1023? Sep 27 18:14:46 or 1023? Sep 27 18:14:53 because 0 does not make sense Sep 27 18:14:55 should be 1023 Sep 27 18:14:58 why? Sep 27 18:15:08 see formula Sep 27 18:15:30 log(0) is not defined Sep 27 18:16:07 aah, i see Sep 27 18:16:25 then your formula is incorrect :P Sep 27 18:17:05 maybe, but is based on some samsung chip and that chip has 2/3 parameters same Sep 27 18:17:40 and after calculating third param it is ok for Doc data Sep 27 18:18:13 raw 1023 = -32.53°C Sep 27 18:18:28 so are any measurements needed, and if so, what? Sep 27 18:18:58 Pali: so this formula gives the same reading as BME? Sep 27 18:19:42 same (+/-1°C) as Doc BME Sep 27 18:20:00 and seems is same on my n900 bme Sep 27 18:20:39 but I did not used DocScrutinizer enterprise solution :-) Sep 27 18:22:03 hmm BTW why not using the formula instead of LUT? Sep 27 18:22:19 Pali: pretty please use a sparse table Sep 27 18:22:45 no natural logarithm function in kernel Sep 27 18:22:46 having 8k LUT does not seem a good idea to me Sep 27 18:23:15 Pali: i can interpolate it to polinomial Sep 27 18:23:17 we fscking don't need a 8k LUT Sep 27 18:23:32 and we don't need friggin interpolation Sep 27 18:23:36 hehe Sep 27 18:23:48 just pick next larger raw value tuple from LUT Sep 27 18:24:03 have one tuple per degree centigrade Sep 27 18:24:27 hmm, sounds sane Sep 27 18:24:43 that way we'll have about 130 ints Sep 27 18:25:17 right Sep 27 18:25:21 range -32 to 98 Sep 27 18:25:33 make that 200 Sep 27 18:25:52 dowe really need battery temp above 95? Sep 27 18:25:56 -50 to +150 Sep 27 18:26:01 hehe Sep 27 18:26:13 seems the sensor cannot read bellow 32 Sep 27 18:26:21 DocScrutinizer05, min is -32.53 Sep 27 18:26:36 oh, ok Sep 27 18:26:53 or, is there way how to call natural logarithm in kernel? Sep 27 18:26:59 and we dont really need anything above 75 (maybe) Sep 27 18:27:00 no way Sep 27 18:27:16 we need 90 minimum Sep 27 18:27:29 DocScrutinizer05: agree, that is why i said 98 Sep 27 18:27:34 but 150 is insane Sep 27 18:27:41 95 c is 'throw t away as hard as you can' Sep 27 18:27:54 since... we would like to put up a highscore eventually ;-P Sep 27 18:28:01 :) Sep 27 18:28:35 Can those batteries withstand temps over 70 deg? Sep 27 18:29:00 yes, particularly because 150 real °C is insane, we want it converted to watch our hw actually *go insane* Sep 27 18:30:17 look, if a user drops in here, asking about "my bat has 75" we all go WAAAAH! duck and cover!! When he comes in with "my bat has 150" we laugh and tell him to take it to a repair shop to swap the thermistor Sep 27 18:30:36 1 = 201.81, 2 = 159.65, 3 = 138.29, 4 = 124.37, 5 = 114.21, 6 = 106.28, 7 = 99.82, 8 = 94.41, 7 = 89.76 Sep 27 18:30:44 this is not very usable ^^^ Sep 27 18:30:57 pretty fine Sep 27 18:31:06 why not? Sep 27 18:31:15 it also doesn't hurt to use those 7 entries in LUT Sep 27 18:31:53 if your raw is over 201, then temp is 2 deg and so on Sep 27 18:32:09 I'd really have 1. and last LUT tupel cover the ADC extrema Sep 27 18:32:38 aah, it is raw/temp Sep 27 18:33:34 ooh, ant it highly unlinear, so we'll have way less that 130 Sep 27 18:33:39 so if ADC/raw is 0 or 1, you output 202°C Sep 27 18:33:48 :nod: Sep 27 18:34:05 naah Sep 27 18:34:13 it is rather 350 Sep 27 18:34:58 if it's in a range of dunno 120...135, you find next lower tupel in LUT which is 120raw=54° Sep 27 18:36:18 for 53° you next LUT tupel is 136=53°, and will get picked for ADC 136...dunno151 Sep 27 18:36:24 get the pickture? Sep 27 18:37:08 basically your LUT looks exactly like my spamming I've done here Sep 27 18:37:09 Pali: what is the precision BME return value has? Sep 27 18:37:13 and on pastebin Sep 27 18:37:29 same, since it's same ADC Sep 27 18:37:40 just other mux chan Sep 27 18:37:48 freemangordon, integer (1°C) Sep 27 18:38:09 ooh sorry, BME not BSI Sep 27 18:38:10 Pali: then we don;t need anything with higher precision Sep 27 18:38:11 but kernel driver must report 1/100°C Sep 27 18:38:23 *100 :P Sep 27 18:38:30 ok :-) Sep 27 18:39:03 it's even insane to get 1° precision from battemp Sep 27 18:39:10 as noisy as it is Sep 27 18:39:32 Pali: we'll never have a really high precision temp measurement because of the differences in thermistors Sep 27 18:39:41 that too Sep 27 18:39:50 and we don't need it in practice Sep 27 18:39:52 but noise is even worse I'd guess Sep 27 18:39:59 so 1deg resolution is perfect Sep 27 18:40:02 what noise? Sep 27 18:40:03 yep Sep 27 18:40:06 absolutely Sep 27 18:40:17 Pali: from ADC conversion Sep 27 18:40:20 for example Sep 27 18:40:27 ok Sep 27 18:40:33 Pali: look at my full dump on pastebin and watch the raw value skip up and down like mad Sep 27 18:40:51 you saw it for capacity calculation Sep 27 18:40:57 I dunno where from it comes, maybe RF interference or whatnot Sep 27 18:41:03 the raw value is not a constant Sep 27 18:41:09 yep Sep 27 18:42:19 hey DocScrutinizer05 Sep 27 18:42:30 i'm afraid my phonet is dying D: Sep 27 18:43:44 kerio: sudo stop sscd && sleep 5 && sudo start sscd Sep 27 18:43:52 Pali: i know Sep 27 18:43:56 that's not the problem Sep 27 18:44:01 the problem is that it needed that Sep 27 18:44:04 D: Sep 27 18:45:39 kerio: and what can I do to make you feel less terrified? Sep 27 18:46:13 DocScrutinizer05: hug me and tell me everything is going to be fine ;_; Sep 27 18:46:37 I have a hard time telling lies Sep 27 18:46:51 k ._. Sep 27 18:46:55 (a lie, a lie!) ;-P Sep 27 18:47:42 I just can tell you odds are you're wrong as usual ;-) Sep 27 18:48:01 phew Sep 27 18:48:26 reflash stock PR1.3 without any leete apps or kernels or whatever Sep 27 18:48:31 test for a few days Sep 27 18:48:37 ew Sep 27 18:48:39 no Sep 27 18:48:50 if problem persists, you probably got a real problem Sep 27 18:49:03 meh, it's probably a flaky SIM anyway Sep 27 18:49:10 if not, somebody else has a real problem Sep 27 18:49:14 or maybe it's smartreflex Sep 27 18:49:27 DocScrutinizer05: ? Sep 27 18:49:40 possible Sep 27 18:49:51 nah, it's not SR :) Sep 27 18:49:55 uhuh Sep 27 18:49:59 rapuyama isn't SRed Sep 27 18:50:09 but maybe SIM power is Sep 27 18:50:16 oooooooooooooooooh Sep 27 18:50:17 I haven't checked it Sep 27 18:50:23 neat Sep 27 18:50:51 hm, where would one check something like this? Sep 27 18:50:52 toldya SR isn't even evaluated to meant to work, on a circuit level Sep 27 18:51:08 maybe they used a LDO for SIM that is considered DSP by SR Sep 27 18:52:05 obviously you check that stuff in schematics, my favourity daily work, so I won't do it today for friggin SR Sep 27 18:52:31 DocScrutinizer05: you could check it with a multimeter! Sep 27 18:52:59 you follow each single connection and read the datasheet specs for all the pins it connects, and ponder if they match and make sense Sep 27 18:53:36 usually, do they? Sep 27 18:54:30 this way you find LP5523 has a IRQ output to OMAP GPIO that 'ideally' can fry your whole SOC since you can switch it to a mode where it supplies Vbat to GPIO which is 1.8V Sep 27 18:54:47 (do they?) obviously not always Sep 27 18:54:56 otherwise I hadn't spotted that Sep 27 18:55:06 woooooooah Sep 27 18:55:16 * kerio ponders about a self-destruct mechanism Sep 27 18:56:25 other "errors" can be on purpose, when e.g. they deliberately decided SR isn't worth it and they better use that LDO for SIM power than for separate DSP power Sep 27 18:56:51 (just a hypothetical scenario) Sep 27 18:57:37 then me and my EE-supapowas have to decide if it's sane and sensible and how it's meant to work, or if they outright fsckd it up Sep 27 18:58:10 if I'm lucky, they left a note in kernel source about it Sep 27 18:58:29 like /* don't use SR here, since this LDO is for SIM! */ Sep 27 19:35:11 freemangordon, DocScrutinizer05: https://gitorious.org/rx51-bme-replacement/rx51_battery/commit/154913d0c633d5903422cabe1178418d1ba7aad1 Sep 27 19:35:25 only two small tables Sep 27 19:36:02 first: TEMP = rx51_temp_table1[RAW] second: RAW = rx51_temp_table2[TEMP-rx51_temp_table2_first] Sep 27 19:50:14 Pali: some weird var naming aside, it looks quite nice Sep 27 19:51:39 e.g I'd not call the var to store result of ADC temperature: >> int temperature = rx51_battery_read_adc(0); << wasn't simple >> int raw << a better name? Sep 27 19:53:38 replace Sep 27 19:53:42 /* ADC channels are 10 bit, higher value are undefined */ Sep 27 19:53:43 114 if (temperature >= 1024) Sep 27 19:53:44 190 115 Sep 27 19:53:47 meh Sep 27 19:54:43 replace >> if (temperature >= 1024) << by >> if (temperature >= 2^10) << Sep 27 19:55:10 or 1<<10 Sep 27 19:56:47 err 2**10 Sep 27 19:57:08 1<<10 is even nicer Sep 27 19:59:02 huh, C has "**" as an operator? Sep 27 20:00:41 It doesn't. Though given int *p, you could write 2**p. (To get multiplication and dereferencing.) Sep 27 20:03:30 nah, it of course hasn't Sep 27 20:03:57 Pali: the following two lines definitely look kinda nonsensical in 2nd line: Sep 27 20:04:00 if (temperature < rx51_temp_table2[min]) Sep 27 20:04:02 123 return rx51_temp_table2_first-min; Sep 27 20:04:57 and lines 124,125 look no less weird Sep 27 20:05:59 I think I know what you intended, but due to suboptimal var names it again gets confusing and might have confused you (or me ;-D) Sep 27 20:07:03 1. if RAW value is < 25 return 53 Sep 27 20:07:06 I'd call min rather tab2_offset_centigrade Sep 27 20:07:48 min & max means index of array Sep 27 20:08:17 Pali: 1. min=0, so if (temperature < rx51_temp_table2[0]) return rx51_temp_table2_first; Sep 27 20:08:58 it is correct Sep 27 20:09:03 so scratch my remark 2 posts above aboiut name of min, I already got confused Sep 27 20:09:03 or why not? Sep 27 20:10:50 actually what you *meant* is: if (temperature < rx51_temp_table2[min]) return min + rx51_temp_table2_first; Sep 27 20:12:01 err, or what Sep 27 20:12:47 omg, you sorted the table as index==offset down from offset-max ? Sep 27 20:13:22 see usage of table2: RAW = rx51_temp_table2[TEMP-rx51_temp_table2_first] Sep 27 20:13:55 yeah, I see RAW there, but nowhere else in the code Sep 27 20:14:13 ah, yes, raw is "int temperature" Sep 27 20:14:24 I will rename "temperature" to "raw" Sep 27 20:14:39 and I'm not interested in calculating RAW from TEMP, no? Sep 27 20:15:02 then invert it :-) Sep 27 20:15:11 why don't you invert it? Sep 27 20:15:32 because it is not possible Sep 27 20:15:38 i c Sep 27 20:15:49 you have more values assigned to one index Sep 27 20:16:16 yesyes Sep 27 20:17:06 still it nukes my mind to figure what's real centigrade Celsius for first entry in rx51_temp_table2 Sep 27 20:18:40 since I'd call rx51_temp_table2_first simply tab2_offset_centigrade_C Sep 27 20:19:47 and explain sort order of that rx51_temp_table2 verbatim Sep 27 20:21:12 maybe I'm too simple today Sep 27 20:21:53 first table is easy and direct: table1[1] = 201 means RAW 1 = 201°C; table[2] = 159 means RAW 2 = 159°C Sep 27 20:23:55 yes Sep 27 20:24:31 but inversion of first table is not injective, e.g 203°C, 202°C, 201°C all have RAW value 1 Sep 27 20:25:43 so it is better so store RAW values 1-24 in table RAW-->TEMP Sep 27 20:26:37 now look at second table. it convert TEMP-->RAW Sep 27 20:28:06 TEMP -31 = RAW 937; TEMP -32 = RAW 993 Sep 27 20:28:37 Pali: so far I already got it Sep 27 20:28:55 huh, C has "**" as an operator? Sep 27 20:28:58 whoops, sorry Sep 27 20:29:06 so first entry of tab2 has raw value for 53°C Sep 27 20:29:14 i meant to do up and enter on a different window Sep 27 20:29:37 DocScrutinizer05, yes Sep 27 20:31:05 another nitpicking: rx51_temp_table2 -> rx51_temp_table_main; rx51_temp_table1 -> rx51_temp_table_aux Sep 27 20:31:51 DocScrutinizer05, so you did not have exam from calculus this month, right? :D Sep 27 20:33:17 /* this rx51_temp_table_aux holds °C values for index[raw] in 1..24 */ Sep 27 20:34:47 /* this rx51_temp_table_main holds raw values for index[°C] starting at offset 53°C for first entry and counting down 1°C for each consecutive entry */ Sep 27 20:36:19 /* raw values in between table entries are using next lower(?) °C value as result */ Sep 27 20:36:57 first table is funcion with domain (raw) [1,24] and second table is function with domain (temp) [53, -32] Sep 27 20:37:59 oops, actually *higer value* since min means high temperature and max means low temperature Sep 27 20:38:42 see why I find this a tad confusing? Sep 27 20:45:58 but I admit your solution is probably more optimized than my more prototypical approach to have one table with (int raw, int temp) tuples Sep 27 20:46:59 and only have one tuple per temp value (like your table2 does) Sep 27 20:47:21 it didn't occur to me to use the index Sep 27 20:48:35 ~6+14 + 25 Sep 27 20:48:35 45 Sep 27 20:48:45 meh Sep 27 20:48:50 ~6*14 + 25 Sep 27 20:48:50 109 Sep 27 20:49:13 additional int, but less code to handle special cases and two tables Sep 27 20:49:53 probably your solution is 80 bytes shorter than mine Sep 27 20:52:43 there is still way how to decrease module binary size Sep 27 20:54:39 only 26 values are > 255, they can be stored in third table (16 bit) and other as 8bit numbers Sep 27 20:59:38 eeeeeek Sep 27 20:59:58 EEEEEEKK! Sep 27 21:00:04 a Sep 27 21:00:07 mouse! Sep 27 21:01:41 btw if you add a 25th array element of 53 to end of rx51_temp_table1, you can save the (anyway incorrect) lines 121..123 Sep 27 21:07:04 it is correct :-) for temperature 54°C there is no RAW value (look at formula and try to assign) Sep 27 21:07:38 only 55°C and 53°C Sep 27 21:07:51 (incorrect since for all other raw values you pick the next lower index (with next lower raw value) in rx51_temp_table2 aiui, in return (rx51_temp_table2_first - min) * 100;) Sep 27 21:08:42 only for this special case you return next higher value Sep 27 21:10:39 sweet Sep 27 21:10:53 ghostery seems to work with microb. Sep 27 21:10:55 but since there's no gap in your raw values between last index of tab1 (24) and lowest value in tab2[0], the case is fictive anyway Sep 27 21:12:46 DocScrutinizer05, no, now I see that line 122 is redundant and it is always false Sep 27 21:13:16 if raw == 24 then rx51_temp_table1[24] is returned Sep 27 21:13:42 if raw == 25 then binary search loop in rx51_temp_table2 is performed Sep 27 21:13:45 and if your tables would look different (e.g. value of tab2[0]=30) then adding 30 as last value to tab1 would catch that again Sep 27 21:14:39 sizeof(table1)/sizeof(table1[0]) is 25 Sep 27 21:14:42