Hi,
In our current research, we want to measure power consumption of an I9250 doing various network related tasks. To do this, one of our electronic wizards must connect his instrumentation tools to the battery pinouts. He told me he needed to know the resistance of the two extra pins (those two except + and -)
Anyone who knows this, or has done something similar?
Best wishes,
Morty
So as I understand it those are not used to provide power for the battery. These other pins are used to communicate with the battery (and if it has NFC) use the antenna embedded into the battery. Your engineer doesn't need to do anything with these but connect them straight to the phone.
Out of curiosity is your research going to get published anywhere? I am really interested in those types of numbers
Hi thanks!
We did similar test on the Nokia N900. For this phone, we had to add resistance to the third pin (the additional to + and -). The results are not published, it was part of a master thesis for one of our students.
The experimentation with the nexus is also part of a master thesis, as always we hope it will end with a publication! We can then provide some results.
Well I don't understand why they need to do anything, if they pass these straight through and tap the power lines the battery should work fine (appear transparent).
If that doesn't work then you have two options. The first thing is to buy a replacement battery and take it apart. The second would be to go into your lab and use a scope/meter to measure those lines and see what they do.
Hi folks,
I have a hardware/software project that I'm building on a Galaxy Nexus phone and I would like to exert full control over the FSA9480 chip that switches the phone's pogo pins and micro-USB port between the USB and charging circuits.
The overall goal is to have a USB accessory plugged into the phone at all times, including in a pogo-pin based charging dock. Since the default "auto" switching mode keeps the phone in USB-host mode as long as the OTG cable is plugged in, the phone will not currently charge in the pogo dock.
Thanks to Adam's great thread on the FSA chip, I've been able to control the FSA chip via the i2c interface, using the i2c tools in his hack pack. (Heading to those threads to leave my thanks as soon as I get this FP in).
Even though I can check the registers and in fact see that the switches inside the FSA chip are in the modes I specify, the phone doesn't do the things I expect it to, like charge or enter USB accessory mode. I suspect this is because I've unloaded the FSA kernel module in order to access the i2c device. I was hoping that merely connecting the wires to the right places via the FSA would do things like enable the USB connection or allow the device to charge. Alas, that does not seem to be the case.
Since Google has declined to share the source for this phone, I've been poking around and assuming that their driver is similar to this code and this header. I love that fsa9480_SetManualSW is exported, but I have no idea how I might access that method, if it is in fact in the Nexus code. I'm searching through the lib/*.so files now to see if there's anything FSA related there, but so far no luck.
So that's where I am - I can control the device, but that doesn't appear to be enough to do the things I want to do. I'm not sure where to go next - I don't think I should have to write my own kernel driver, but I'll be damned if I know what to try next.
Does anyone have any ideas how I might exert software control over this FSA chip, or barring that, what else I need to fool with on the i2c bus so that the phone charges or enters the proper USB mode when I set the FSA mode manually?
Many thanks in advance and I hope this is the right place for this question (Q&A section did not seem like the place for this type of question).
Peter
You're taking an interesting approach to this. However, there are a couple of things you need to explain and understand better.
1) What are these "pogo-pins" you're talking about? [There is no such thing well defined, please be specific and use correct terms for whatever it is you're trying to describe.]
2) What make you believe there is a FSA9480 in your Nexus? [There probably isn't! I know the driver is called so, but that chip probably never existed in production.]
3) Obviously (!) you cannot charge your phone and have it play (OTG) host at the same time. Why? Because charging means to short D+ and D-.
4a) You say you can "control the chip" with I2C, can you give some examples of this? But I don't know what you're actually controlling, as it doesn't make sense the way you have explained it.
4b) You also say you have unloaded the Kernel module... How did you do that?
5) It seem that you're confusing the chip signal directions. I.e. whether certain pins are designated as input or output signals...
6) There are more switches/multiplexers built into your phone. It's of essence to understand which ones you're actually controlling.
E:V:A said:
You're taking an interesting approach to this. However, there are a couple of things you need to explain and understand better.
Click to expand...
Click to collapse
Certainly happy to explain as much as I can... let's see:
1) What are these "pogo-pins" you're talking about? [There is no such thing well defined, please be specific and use correct terms for whatever it is you're trying to describe.]
Click to expand...
Click to collapse
I got the term "pogo pins" from this thread. They are three tiny pins on the side of the Galaxy Nexus. They allow for car and desktop docks. They provide charging through the outermost pins and a digital signal of some kind (don't care about that one for this project) on the center.
2) What make you believe there is a FSA9480 in your Nexus? [There probably isn't! I know the driver is called so, but that chip probably never existed in production.]
Click to expand...
Click to collapse
I've simply assumed from the kernel messages and from screwing around via the i2c bus (as explained before). It may not be there, it may be something completely different, but from the software side, it behaves exactly like I'd expect the 9480 to...
3) Obviously (!) you cannot charge your phone and have it play (OTG) host at the same time. Why? Because charging means to short D+ and D-.
Click to expand...
Click to collapse
Yes, I glossed over that fact. Expansion: We've got a USB accessory that we would prefer to never disconnect from the phone. Since even having just the OTG cable connected drains the battery, our app is already managing power by binding/unbinding the fsa9480 driver. When unbound, the driver leaves the phone pins in (afaik) a floating state and the accessory/OTG cable does not draw current. When we want to poll the accessory, our app binds the fsa9480 driver, which results in the USB system seeing the OTG cable and connecting everything up nicely. When it's done, it unbinds the driver again and saves battery.
Since we don't want to/can't disconnect the accessory from the micro usb port, charging is an issue. So we'd like to charge the phone via the side pins (what I perhaps erroneously called the "pogo pins"). Since we're only polling for short periods, we'd like to be able to switch from USB host mode to charging mode during the period in which we are not accessing the device.
Now, I had forgotten that dedicated chargers short D+/D-. My hope was that by controlling the fsa9480, I could connect the +5V and GND pins to the battery and charge the phone, while keeping the USB accessory offline. I'm afraid I'm so tired and burnt out this may not be making sense, so please tell me what's confusing!
4a) You say you can "control the chip" with I2C, can you give some examples of this? But I don't know what you're actually controlling, as it doesn't make sense the way you have explained it.
4b) You also say you have unloaded the Kernel module... How did you do that?
Click to expand...
Click to collapse
Sure! Where to start...
OK, so based on Adam's thread "Build Your Own Music Dock", linked above, I grabbed the spec sheet for the fsa9280a, which he claims is "functionally the same" as the 9480.
As you can see in the datasheet, the chip is controlled via the i2c bus. Looking at the file layout of the Nexus, I figured out the address of the chip on the bus and started plugging in commands outlined in the datasheet.
for example, setting the "Manual Switch 1" register on my Nexus is done by the command
Code:
i2cset 4 37 19 <your value>
(4 being the bus where the chip is located, 37 (0x25) being the address of the device, and 19 (0x13) being the address of the register)
The datasheet outlines all the register addresses, default values, values under certain conditions, etc. I assured myself that the datasheet was valid and I was communicating with the device I thought I was by setting and observing registers.
That "Manual Switch 1" register controls where the different wires are connected and is very important to me, as far as I know.
this is the block diagram from the spec sheet in Adam's thread above. I should have linked directly to the spec sheet, sorry.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
And this is the register description from the same document
So... let's simplify my goals and say that I want to charge the phone from the micro usb port without connecting the USB host device (USB HS in the block diagram) to the micro USB connector: I'd want DP_CON and DM_CON floating and Vbus_in (on the micro connector) connected to Vbus_out (on the blue CHARGER IC in the upper left). I set the proper registers to do that, and things "should just work", right? (this is assuming I do things like initing the device, etc in the proper order, which I think I am)
They don't. Because I'm confident that the proper registers are set on the FSA, I'm assuming that the internal connections are all as I expect. Thus, my suspicion is that I need to do something more to get Android to start charging off the current coming in through Vbus_in...
Oh, and before I forget: unless I unbind/unload the driver for the FSA9480, I can't write to its address via the i2c tools because the driver already owns that address. I think of this driver as a kernel module, maybe that's incorrect or imprecise. Apologies.
5) It seem that you're confusing the chip signal directions. I.e. whether certain pins are designated as input or output signals...
Click to expand...
Click to collapse
I hope the block diagram cleared this up. I too was confused by the Vbus_in/Vbus_out thing. I really should have linked that datasheet.
6) There are more switches/multiplexers built into your phone. It's of essence to understand which ones you're actually controlling.
Click to expand...
Click to collapse
Agreed.
With that massive clarification, does that help? I'm starting to think this is something hovering right at the intersection of hardware and software. Maybe it's time I looked at writing my own device driver, or expanding the existing one?
E:V:A said:
3) Obviously (!) you cannot charge your phone and have it play (OTG) host at the same time. Why? Because charging means to short D+ and D-.
Click to expand...
Click to collapse
You had better explain that slowly to my Nook, because it's sitting beside me here charging and connected to two keyboards and a USB audio adapter.
Shorting D+ and D- is a convention to tell the device that it can draw a lot of current.
Even without the data lines shorted, a device can charge.
Moreover, if you tell your device in software to do a high current charge, it can.
Solution: use host mode and charge at the same time.
One connector does it all.
One thing I noticed while playing with the FSA chip was some of the registers would not change. They may be overridden by resistor values.
To put the device in host mode, short pin 4-5. To put it in charging mode short 3-4. It may be possible to change the host mode to charge the battery over i2c.
This may or may not be possible.
The main problem I was having was in the SBL most registers would stay static.
Playing with I2C sounds like fun, but all that stuff already has drivers.
The drivers that I've seen already have user hooks in the file system to get things done.
For example:
Code:
echo 1500000 > /sys/devices/platform/bq24073/force_current
Sets the charging current on a Nook touch to maximum.
(Your device probably uses something different.)
@Renate NST: Yes, I should have been more careful with my words. I meant charging as operating as a high current Dedicated Charging Port (DCP). But then again thebeerbaron already understood this.
@thebeerbaron: Here are your "pogo-pins" (right side is towards the top of the phone):
The pins and their function is loosely described in this thread, and very nicely used in this thread, so it seem that the following is true:
Code:
[SIZE=2]P1 +5V
P2 Signal: 1-wire interface, using MFM encoding
P3 GND[/SIZE]
(check these!)
I don't have the Samsung parts list of the GT-I9250 so I still don't know what those chips are. But U601 is a Fairchild chip and could be another type of switch. On the other side of this board you find the multiplexers U809 and U810 configured like this:
So how did you unbind/unload that "driver"? [I'm curious to see what driver/Kernel module this is.]
And here is another relevant hack for a wireless charger, But the interesting part is the Kernel hack mentioned:
For those of you wanting to charge at AC speeds instead of USB, Fast Charge Mod is here!
1) Install Franco Kernel (Milestone 1)
2) Run this script to activate it from the terminal (minus quotes):
Code:
echo 1 > /sys/kernel/fast_charge/force_fast_charge
and the UI Mode Manager code over here.
E:V:A said:
I meant charging as operating as a high current Dedicated Charging Port (DCP).
Click to expand...
Click to collapse
Ok, but I can still pump 1.5 Amps into my Nook while using host mode.
I'm not sure how you are differentiating things here.
Renate NST said:
Ok, but I can still pump 1.5 Amps into my Nook while using host mode.
I'm not sure how you are differentiating things here.
Click to expand...
Click to collapse
Well, Samsung try to conform to the "Battery Charging 1.1" standards, and that's how DCP is defined in there. The limitations are then also present in the chips and/or in the one or more PMIC Kernel drivers. So your NST is either not conforming to any standards or just have a hell-of-a-hacked Kernel, or both.
This project is interesting because it's exploring some hybrid between kernel hacking and hardware tweaking, and not just building a regular charger, which we all know how to do. If you are interested in knowing what kind of crazy hardware is included in a Galaxy class Samsung phone, you can have a look here.
Generally speaking, as far as standards go, you're not supposed to even try to charge something while it's in host mode.
Still, it's a useful thing to do if you want to use your device docked.
The kernel on my Nook is stock. I'm just giving commands to control the charge current.
Renate NST said:
Ok, but I can still pump 1.5 Amps into my Nook while using host mode.
I'm not sure how you are differentiating things here.
Click to expand...
Click to collapse
I don't know about the NST, but my Nook Tablet has several additional pins dedicated to charging the device, it's not a true USB port.
What's going on here is trying to convince the USB port to go into host mode, where it natively supplies 5VDC, but instead reverse it, use the 5V line to charge the device and supply 5V from an external source.
While the NT has a dedicated charging circuit, this device repurposes its usb pins based on input conditions. So here's what I see being required
1. Ground USB pin 4 to activate HOST mode.
2. shut off 5V power supply from FSA chip
3. set registers in FSA to charging mode.
Renate NST said:
Generally speaking, as far as standards go, you're not supposed to even try to charge something while it's in host mode.
Click to expand...
Click to collapse
It's pointless to discuss standards of what should and should not happen unless we are on the same page. Here are the specs.
Sorry.
/me wanders off elsewhere.
Sorry for the slow reply folks, I appreciate the input, but got sidetracked onto another project today. Wearing many hats means making a lot of context switches!
Renate NST said:
Shorting D+ and D- is a convention to tell the device that it can draw a lot of current...Solution: use host mode and charge at the same time.
One connector does it all.
Click to expand...
Click to collapse
I haven't tried charging during host mode, as we were trying to keep the external wiring changes to a minimum. Based on what I found last night though, we may go with a completely external solution...
AdamOutler said:
To put the device in host mode, short pin 4-5. To put it in charging mode short 3-4. It may be possible to change the host mode to charge the battery over i2c.
This may or may not be possible.
The main problem I was having was in the SBL most registers would stay static.
Click to expand...
Click to collapse
If we go with the external wiring solution, this will be what we do. When I set the FSA to various modes over i2c, it did not charge or connect the USB device as it should. This is very likely because the kernel is listening to the FSA for state changes and telling other devices how to behave based on those states. That's sad.
What is the SBL?
Renate NST said:
Playing with I2C sounds like fun, but all that stuff already has drivers.
The drivers that I've seen already have user hooks in the file system to get things done.
For example:
Code:
echo 1500000 > /sys/devices/platform/bq24073/force_current
Sets the charging current on a Nook touch to maximum.
(Your device probably uses something different.)
Click to expand...
Click to collapse
Yes, this is how things should behave. Unfortunately, the Samsung engineers who wrote this device driver were rather short sighted.
If you wade through this mailing list discussion (sorry, I apparently can't link until 8 posts... https://lkml.org/lkml/2011/6/29/124), you'll see the engineers need several attempts to get their code approved. The most interesting part to note (for me), is that they create the device file /sys/bus/i2c/devices/.../switch, which accepts input from userspace and sets the FSA9480 "manual switch 1" register appropriately. Unfortunately for me, they only coded a small portion of the possible states for this register and will not accept arbitrary values. UGH!
I sat down with the GN last night and tried using the /sys/bus/i2c/devices/.../switch device to set the manual mode. What I discovered is that even though this obviously passes values into the driver module (it prints a kernel message when I set a bogus value), the values don't "stick". In the driver code (I'm still not 100% sure I have the right source, but I think I'm close.. again, sorry for lack of clickability: https://bitbucket.org/franciscofranco/android-tuna-omap/src/388ae9aa9b26/drivers/misc/fsa9480.c), it has a _detected function, which gets called whenever the cable changes and overrides any manual settings I put in. For example, I set the "switch" file to "AUDIO", yet the phone remained in USB accessory mode, and plugging/unplugging did nothing. Sigh.
The lesson is, apparently, that I need to write my own driver module, which can replace this fsa9480.c transparently and allow me to ignore cable change detections and provide me with a way of setting the FSA state manually (with more flexibility than the Samsung engineers allowed). We're thinking about a different approach, but this may yet get done...
E:V:A said:
So how did you unbind/unload that "driver"? [I'm curious to see what driver/Kernel module this is.]
Click to expand...
Click to collapse
Some great background info in here, thanks! I'll have to sit down and process this another day.
To unbind the fsa9480 driver, I do:
Code:
echo -n "4-0025" > /sys/bus/i2c/drivers/fsa9480/unbind
And to bind it, I do:
Code:
echo -n "4-0025" > /sys/bus/i2c/drivers/fsa9480/bind
E:V:A said:
This project is interesting because it's exploring some hybrid between kernel hacking and hardware tweaking, and not just building a regular charger, which we all know how to do.
Click to expand...
Click to collapse
Yep, that's what's interesting and what's making this difficult. It's kind of a gray area of where the topic experts are and what I need to learn...
Thanks for your input all... maybe something will come along that'll save me from writing a kernel module... fingers crossed!
I am very interested in the outcome of this project. I purchased the GNex thinking I could charge it while at the same time, connecting an SSD (via SATA->USB converter) to the phone for media playback. Thanks for your hacking skills!
Renate NST said:
Generally speaking, as far as standards go, you're not supposed to even try to charge something while it's in host mode.
Still, it's a useful thing to do if you want to use your device docked.
The kernel on my Nook is stock. I'm just giving commands to control the charge current.
Click to expand...
Click to collapse
Not true. https://github.com/CyanogenMod/andr...mmit/c7016a2513abfd522b02633b79d2f21bcb99d4e2 - The USB charging standard defines an Accessory Charger Adapter. It's signaled with a particular resistor value (36k if the code comments are correct...) on the ID pin.
Although while I thought the I9100/I777/N7000 used an FSA9480, it looks like the MAX8997 handles the task on these devices... hmm... The FSA might support this mode though, so instead of trying to force-override it, look to see if there's a particular resistor value you can hijack or, in this case, a resistor value that is standardized to provide the function you want.
I hate when I only have access to github's web interface and not the ability to grep my hard drive at home.
So I had bought three Stratospheres for cheap (bundle auction), hoping that I'd be able to pick up another cheaply with a good screen or bad glass+good LCD. However, beings I've not taken one apart to that extreme I wasn't aware how hard it'd be to separate those pieces At any rate, they all work fine otherwise, I know at least 2 boot to Android since I eventually get the haptic vibration indicating it'd reached the unlock screen. I had also hoped that at the very least the Wiki would've been right about HDMI out, but it's hard to find out what all have full support (the Epic 4G [D700] I got instead for example has it mostly but no one's able to get it working).
New screens cost the same as a working Strat, and seeing as I already bought an Epic after finding that out, I'm wondering what to do with these. I love tinkering, so being able to solder in a Composite, VGA, DVI, HDMI video connector and use it as a self-powered Stick Computer would be seriously awesome.
I'll gladly take hi-res PCB photos, with a DSLR and ample (non reflecting) light, if folks want to help tackle this Hell, for that matter... if you've got the know-how and want give it a try, I will give you one of these Strats to see what you can figure out. These aren't like the Epic as far as PCB goes, either. That Epic is very tiny and a fraction of the phone's size, but these Strats are pretty much the full phone's length and width, so lots to play with lol
Anyways, hope someone knows a thing or two and we can figure a hack out!
Thanks.
EDIT: This just came to me...What about something like these, in conjunction with a ROM (preferably Odin flashable) that has USB Hub support?
http://www.monoprice.com/products/subdepartment.asp?c_id=101&cp_id=10114#1011403
Unfortunately it isn't driverless, BUT it does list Linux support, at least on the VGA model! More than I'd like to spend given the project, but we can call that Plan Y (Plan Z being: buy a new screen lol)
Ez way - how about flashing with some latest ROM and enabling tvout (with help of screenshots from DDMS)
Then you can connect any cheap stuff decoding pal/secam and maybe an otg keyboard/mouse + power chord through hub or straight to the batt slot.
The tryhard way - you could try to exploit screen flex slot. You should find 16/24bit rgb dpi'ish interfrace there + 2 i2c/spi busses and some gpios. Maybe utilising it as 16bit rgb going to sort of converting circuit could leave you with like ~15gpio pins for mostly any kind of stuff u want (spi, i2c, irqs). You need a good breakout for that and gotta consider high frequency layout (as rule of thumb, try to make wires between consecutive ICs as short as possible and equal length)
Capabilities and possibilities are unlimited. Just human's imagination and life is.
Id be careful with usb-dvi converters. Might work. Might not. Check with otg keyboard or smth first.
Rebellos said:
Ez way - how about flashing with some latest ROM and enabling tvout (with help of screenshots from DDMS)
Then you can connect any cheap stuff decoding pal/secam and maybe an otg keyboard/mouse + power chord through hub or straight to the batt slot.
The tryhard way - you could try to exploit screen flex slot. You should find 16/24bit rgb dpi'ish interfrace there + 2 i2c/spi busses and some gpios. Maybe utilising it as 16bit rgb going to sort of converting circuit could leave you with like ~15gpio pins for mostly any kind of stuff u want (spi, i2c, irqs). You need a good breakout for that and gotta consider high frequency layout (as rule of thumb, try to make wires between consecutive ICs as short as possible and equal length)
Capabilities and possibilities are unlimited. Just human's imagination and life is.
Id be careful with usb-dvi converters. Might work. Might not. Check with otg keyboard or smth first.
Click to expand...
Click to collapse
So TVOut on the does actually Stratosphere work? (with a custom ROM, I mean)
You happen to know where to find such a ROM? I know that XDA doesn't have a Strat subforum I've looked high and low, and can barely find custom ROMs, let alone one that's TVout lol Everything is still Gingerbread based, but I suspect that doesn't matter since the hardware is from that time.
As for the latter, I actually hadn't realized that without a screen, I'd be without a MOUSE haha I was totally focused on it having a slider keyboard and somehow missed I'd still need a mouse Nevertheless, doing it myself would be pretty hard :\ I don't know that much about the finer details of hardware, at least circuits of that complexity. Modding an analog audio circuit with new capacitors or an OpAmp is one thing, but that's straight forward In-Out, Power-Ground lol
That isn't to say I wouldn't attempt it but I'm not sure exactly what would be needed. If it's LVDS, I do have an older 15" laptop screen that'd be cool to hack a Strat to use :cyclops: That's adding a bit more complexity to things though, at least to start with right out of the gate.
Sadly I dont know where to get Strat ROM. But I assumed that its HW is pretty much the same as I9000, except the additional keyboard, so aries kernel with patches might/should/could work. There shouldnt be any major problems in porting it. I would get these crappy Sammy sources for I405 and I9000, diff them and try to apply diff on kernel_samsung_aries repo of CM.
About TVOut - it is matter of one or two gate ICs and a jack sensing onboard, as S5PC110 has built in tvout signal generator. So I would expect HW to support it.
Edit: There should be some tvout handling in original kernel sources if it is supported. Though, knowing Sammy, there might be aswell tvout driver enabled but HW not wired at all to support it.
Hey everyone, I just made a device for my nook that allows me to "sit back and enjoy" my book with my hands free (nearly free)
This was my chance to be a little useful on this board for once, so here is the detailed article about it, I hope you enjoy it.
spoiler : if you do what I did you actually get to bypass the matrix using a phone
I hope this link pointing to my own blog is not against forum rules by the way, please tell me if it's the case and I'll fix it.
Cheers
K.
Nice work! You're even lazier than I am. :laugh:
I have a foot pedal set up like that using a scrounged keyboard.
I use the PAGE_DOWN codes (which wasn't formalized until after our Android 2.1).
I didn't bother tracing out anything, besides, I only had the tiny PCB itself.
I just ran a shorting wire over stuff until I saw the right keycode on UsbMode.
You may have noticed already, we need to do some work on getting USB host mode to use less current.
Right now, it uses a lot, between 50 mA and 150 mA.
That's a lot, considering that the idle current is less than 10 mA.
Haha thanks I knew you must have built something along those lines already!
The foot pedal was on my list too, did you build the pedal yourself or did you use something?
Yes I did notice the drain... That's really a shame, I was shocked to see my nook completely drained after one night on host mode (I forgot to set it back to peripheral)
Which takes me to a question I planned to ask you
Do you know if it's possible to charge the nook while in host mode? it would solve the drain problem for me, but that would probably be too good to be true...
EDIT : just found that :
http://forum.xda-developers.com/showpost.php?p=32724951&postcount=8
How to
http://forum.xda-developers.com/showthread.php?t=1828032
It's pretty basic... Just connect Vcc and ground to the rest
have you tried something like that ?
cheers
K.
The foot pedal thread is here: http://forum.xda-developers.com/showthread.php?t=1709914
Instead of using a Y cable I use a "back-powering" hub.
Making a back-powered hub is here: http://forum.xda-developers.com/showpost.php?p=22956658&postcount=103
@Karibou3 What is the mount on the back of your Nook?
Renate NST said:
@Karibou3 What is the mount on the back of your Nook?
Click to expand...
Click to collapse
Oh it's an ugly and hasty modification of the original one (first picture in my post) I basically cut off the hinge, put an elastic band between the two remaining parts (you may have noticed it holds and bent the end of the the pincers (if that's the adequate word)
it's ugly but it does the job for now. I'll try to make up something more elegant later (probably involving rubber and claws to make use of the indents, I tried that before to fasten my book LED to the nook and it works well)
Thanks for your advice on the back powered hub, I think I might modify one later but for now I'd like to add power to this particular build (trying to keep it simple) I tried to tap into the Vcc and GND of an USB cable connected to my computer, while it charges the nook in "peripheral mode", no luck with the host mode... So I can't use my remote and charge the nook at the same time
Am I doing something wrong? what are your settings you use with your hub (should be the same right?)
Foreigner here, please be kind =)
Hello everyone, good morning, good afternoon and good night!
Recently I have received some orders for laboratory supplies accompanied by a temperature Datalogger that performs the recording and storage of the temperature history for 11 days.
I've been researching the model and it is for single use and disposable (TempTale 4 USB - Dry Ice version by Sensitech)
I also discovered on some foreign websites that although there is software from the manufacturer to "unlock" the device for later reuse, the acquisition is not compensated due to the low value and the existence of other reusable models of the brand itself (Sensitech).
As this model came by surprise in my hands and no one has other uses for it, I decided to disassemble it and analyze its hardware. It has an Atmel controller that in my opinion could be reprogrammed to reset the programming or even unlock it for other uses.
If possible, I would like to count on the help of experts here on the forum for this. I believe I have come to the right place for this!
I leave some internal and external photos of the device for you guys
drive.google.com/drive/folders/1kON9AvEiRVNXjbIdCbus7JY8tHV3H36N?usp=sharing
It is worth mentioning that it has an interesting system that when connecting to the computer automatically generates a pdf report with all the data and graphs of the temperature record and another .ttx file that I still don't know what it is. Both are also in the drive folder for you to look at.
Hello there, your thread is kinda old by now but I am working on this myself.
Unfortunately I cannot provide you with the software for Sensitech dataloggers due to it being a bit risky, I do not want to get into legal trouble with Sensitech or getting fired for a hobby project. However even with the software you won't be able to reset one without somehow altering the chip contents. It will give you an error message that the dataloggers are meant for one time use only and cannot be reprogrammed.
The way to reset them is to manually erase the content of the ARM chip on the board, I don't know much about microchip programming but I have gotten it to work myself completely by accident. Probably by measuring each pin with an oscilloscope probe I have somehow corrupted/erased the programming on this chip. After that a red light started blinking and the word SET appeared on screen. After that I was able to reprogram them.
The TTX file is a more detailed database of the temperature logs, from which you can extract CSV files and do some sort of fancy graph displays and all that. The PDF is just for general overview.
You have a different model than the ones I get though. I have found that by shorting the Winbond chip and rebooting the device (shorting the battery connector briefly) it goes into some sort of error state. The screen will blink and every time you press Stop the actual temperature will be displayed on the screen. I do not know if your model has this too.
Is anyone still working on this? I have an interest in discussing repurposing a temp tale and would like to discuss