It seems it will be relativly easy to implement NRF24 module mode..
using the ADC pin as the interrupt, and the aux pin for the TX/RS strart up, (CE pin of the module) it uses simple SPI protocol, with few commands etc...we could even make a cable for it.. or a addapter pcb...
did some register read/writes, without any problems using the SPI connections..
It's an interesting little device. You set the location and pitch of the little spring loaded pins, and you connect up any Li Ion battery.. and it gets charged... Now the interesting part is that the charger will safly charge batteries no matter how you connected the + and - pins... you can connect + to the left one and the - to the right one, or the other way around and it will work without issues... No third pin means no thermal monitoring, but from what I figured out it charges at only ~300mA, and from the charging tests I made, the batteries bearly got heated at all, far less then when charged through my phone..
I was intrigued so I opened the little thing up to see how it works..
It has the classic simplest and cheapest flyback (optocoupler + zener) controlled 5V regulator.... nothing worth mentioning there.. But the battery is connected to a DIP 8 IC with markings mt1151D.
with pin 1 connected to one of the batttery prongs, and a bypass cap. pin 2 is NC, pin 3 connects to a charging LED.. forgot where pin 4 is connected (probably GND). pin 5 and 6 are GND, pin 7 is connected to the second battery prong, also bypassed to GND, and pin 8 is connected to VCC...
Offcourse searching for this IC online has proven to be impossible, does anyone know of a similar charging chip that can do this as well..
We've kicked BP development in high gear! For the last few days we've been clearing out the backlog of Issues, and I guess this is a good time as any to move to version 6.3 beta... as of SVN rev 2088... Find attached the hex files for BP version's 3 and 4.., or compile from the latest source code in the SVN..
The other problem appeared to be a resolution issue. As an example, while measuring a 2Hz frequency, the measurement was often 1Hz. So I decided to take a stab at improving frequency measurements. I decided to use the prescaler only when necessary. I also decided to measure the period and divide for low frequencies.
Clutch pedal added to all protocols. output pins are now only connected once the turn on power supplies 'W' command is issued. they are disconnected again if 'w' command is issued (power off)... multiple repeatitive engage/disengage are posible...
Here is the Smoke Tester (wiki). It's a board designed to safely power you prototypes, and check if they have a short somewhere. Also included is a current measuring feature on which output the current could be read using a voltmeter. Here's the full feature list.
5V and 3.3v voltage regulators 7V-15V input 3 possible input sources: USB, 2mm DC barrel jack, and screw terminals 3 possible outputs: USB, Banana Jacks, and screw terminals Polyfuzes with fuse blown LED indicators on both rails Current to voltage converters - aloes you to read the current simply with a voltmeter Jumpers to bypass the current measurement shunts Jumper to bypass the 5V voltage regulator, allowing you to power the 5V output rail directly from the USB input
This design was though up as something we'd like to use in the workshop, but if enough people like it, it might go into production as well. We were inspired by Schazamp's "USB Power Supply with Resettable PTC", we strongly suggest you check it out.
Prototype boards will go out soon with any updates. If you have any suggestions please leave a comment below, or check out the forum thread about it.
I've been working on the Bus Pirate Demo Board v5...it features a PIC16f that emulates varius different ICs such as I2C EEProms, ADCsm DAC etc...
and I'm stuck on the I2C EEPROM :( Ii emmulates 24LC type single byte adressed EEPROMS (so 256 bytes of space) I got it to work fine for single and bulk writes...while the Read operations only work in singles...bulk read always returns giberish for all the data flowing the first byte...
Does anyone have a working example of a I2C slave configured PIC that supports bulk reads....(using HW MSSP module).. Here's the code...
Hi, I'm continuing Sjaaks work on the demo board v5 firmware, I made this topic so you could add suggestions, and help me out a little :) Sjaak, could you tell me what's that status last time you looked at it, any bugs you remember, etc...What need to be done for completion..etc..
if you could write a short (hopefully) description of the code..it would help me a lot, thanks Also, any suggestions on what should be addressed first etc are welcome...
Here is a little design I made based on eariler designs, and arhi's commetns [attachment=1] It features 2 sheets as now, with two additional ring sheets.. that serve as standoffs and side protection at the same time... [attachment=0] only bolts and nuts need to bee used, like this combo for example with the holes on the bottom layer slightly larger to accommodate these kinds of nuts....also the design is much tighter..
I really like the black lower layers with he top transparent. the Black/RED(board) contrast looks cool, at least in SU it does... this could possibly be cheaper to do then 8x bolts, 8x standoffs...
the standoffs ring are 2.55mm in high, most of our board components should fit, but for higher components, either cutouts on the top could be made, or another Ring could be added...
<rant><RANT>I just got an Android 2.3 phone, and a day later, I started my first app for it :D...it's still in the very early stages, but I intend to make a game I used to play with my classmates in high-school, it's 4 in a row but with more then 2 players...we used to play in 4 or 6 people....but nvm the app will use BT....this got me thinking what cool project I could make with BT. This BT idea will be at the bottom of this post, first is the USB example of the same thing</RANT>
If you skipped the rant above, as any same person would, here is the idea. Additional, or supplemental firmware for the LCD Backpack...called LCD debugger. Instead of driving a LCD, another board drives it as a LCD, and the LCD info is displayed over the USB on a Processing (or Java) App...
The app looks like a 44780 LCD and the system LCD Backpack -> Processing app act exactly as a LCD would.... The coding for this should be relatively simple. the LCD backpack, receives commands recognizes them and passes them on to the processing app which displays them.
The second thing I wanted to build is a LCD Backpack, but instead of USB, it runs over Bluetooth....same thing as the USB...it should be able to display and debug 44780 LCD over a Bluetooth connection and a Android app...So instead of fixed screen LCD you have a portable app......
(on another note, this could be implemented by making a Bluetooth module -> USB host board, that would act as host to the LCD Backpack</rant>
While writing the PICtris post, an idea hit me for cool prototyping areas. I really hate the single pin ones. Rows of pinholes going from one end to the other are an improvement, but not by much... anyway here's my idea..
5 blocks connected between each other with cut-away traces...in the sign +....
in this config you can get 4 pinholes in-line each connected to a different 5block group, also available is a square of 4 pinholes with each one connected to a different group as well
Well since the free PCBs started arriving, I think its a good time to start a separate thread for the Part Ninja.
Part Ninja V1 is a electronic component testing tool. It identifies electronic components like transistors and FETs, determines the pinout, and measures basic specifications. Several SMD footprints are included so surface mount parts can be tested too.
Only a few pins and resistors are needed for the transistor tester, so we used the extra PIC hardware to add extra features. A voltage reference along with the PIC’s comparators should help us measure capacitors somewhat accurately. In many designs there are dead spots where resistor measurements are not accurate – we added an extra resistor ladder with a wide range of values to compensate.
*Determines pinouts and key values for transistors, resistors, capacitors, diodes and more *PCB that is the same width of a 2×16 44780 character display *Has a small area where SMD components (SOT23, 1206, 0805, 0603, 0402) can be tested *PWM generation on two pins for advanced testing *Comparators on two pins for advanced capacitor measurement
This is just our first development prototype to get familiar with how semiconductor testers work. This design borrows heavily from other DIY testers, such as the AVR Transistor Tester. We hope to develop it further into a simple-to-use semiconductor tester and LCR meter, then release it as a project at Seeed.
Now I am a total beginner when it comes to USB so this was my head first dive into it. Since the design for the board called for all Through hole components and some constrains dimensional. (the with of the broken out pins was set at 700mils, thus leaving lots of room on both sides of a standard bread board for wire connections.
Now because of this witch constraint the crystal couldn't be placed as close to the pins as I would have liked. So the first thing I wanted to test on the board was the USB and see if it woks as intended.
To get the most stable result I used a 8Mhz primary harmonic crystal (higher frequency crystals tend to use higher harmonics, and are more prone to noise)
So the first thing I did was try to use the CDC Basic Demo (demo in future use) found in MAL. Easy right. Wrong. it is only setup for MX4xxx and MX7xxx series of PIC32s. and theses MX1/2xxx use some different configurations. By just changing the uC used in the demo project resulted in lots of warnings.
So the only thing left was to port it to my uC. I made a new project, and started copying the code that was intended for the 32MX460.chips, and disregarded the rest.
*looking through the code you will stumble onto things like #id defined (__32MX_460***) etc. copied those, spiked all else. Also I spiked including the hardwareprofile.h but copied only the relevant stuff into main.c Skiping all functions that were related to board specific stuff, like LEDs and Swithches.
once I did that, and setup my Configs, the #pragma stuff for my crystal, and lots of browsing to include the relevant header files from MAL into my main.c and usb cdc related .c files. (basically just hitting build and finding the include error and fixing the link) once all the include errors were fixed the project build successfully. I quickly took my pickit3 and programed the board. stuck the usb jack in and crossed my fingers. And I as greeted with Windows 7 message Unknown device, error 43.
I used the suggested added configs and added the code to my main.c which he suggested. The one thing that surprised me was that in order for the CDC to work properly USB_POLLING must be defined in usb_config.h instead of USB_INTERRUPT.
Once this was built, and programed, I was warmly surprised by windows finding CDC-RS232 :D:D:D Below are the configs needed to get it to work with a 8mhz Cristal with the CPU running at 40MHZ
Hi I am interested to know your experiences on the time it takes to make your boards, and ship them to you. I am mainly interested in DorkBotPBX, and spark funs BatchPCB, but any experience is welcome. Thanks.