ejovrh / misko Goto Github PK

an electrical schematic showing all elements shall be drawn in some program or on paper.

test case:
connect e.g. lcd mosfet gate to 50, put on high, upload, check power status of lcd, retest with low state
power state was not consistent

the current approach uses FAT and writes with 1Hz frequency to the card.
data written is about 2X80 characters (with current NEMA sentence selection) - the card is literally burned since there are lots of writes to the same blocks.
this leads to heavy and unrecoverable FS corruption and the card can eventually be thrown away.

implement:

• SD card utilization which will mitigate excessive writing to the same blocks
• a buffer which will hold NMEA sentences in flash memory and e.g. once in 5 minutes flush its contents to the SD card
• devise a way to read out SD card data without the need to physically remove it from the device
• enable card space utilization statistics, display them on a LCD

print the holder via shapeways

their current state is a disgrace; copy and paste code.

at the moment the screen only gets refreshed on button press.
implement a mechanism which will refresh the screen only if it is turned on every 1s for example

the display shall power off after the time period configured in the appropriate eeprom field

implement button press for power toggle.
e.g.:
0-1s - power for 20s
2-3s - power for 40s

double click: toggle power on
double click again: toggle power off

perhaps time setting could be implemented by a default and adjustable by LCD menu item

weird issue: the 1st read returns 0, subsequent reads return proper values

at the moment each startup is essentially a cold start.
see if this can be sped up by providing a position hint or similar.

additionally, see that the last coordinate position is somewhere remembered and displayed.
additionally, check that transitions from fix->no fix and vice versa do not produce garbled display.

a temperature sensor shall be implemented and the temperature shall be displayed.
parse frequency shall be a sane ammount of time - e.g. once in 5 minutes

at the moment the time is obtained by GPS GPRMC sentence.
the timefield in there is GPS-time, not UTC.

fix the code so that proper UTC is displayed and not GPS time.
furthermore, fix the code so that displayed time is in accordance with the UTC setting in the eeprom and that the displayed date is in accordance to 235959 -> 000001 change (next day should be visible in the datum)

for (int i = 1; i < 20; i++)
// for (int i = 1; i < strlen(string); i++)

• 5 buttons: left, right, up, down, bluetooth toggle
• use hardware debouncing (I'm too lazy to code it) [schmitt trigger]
• in software, digitalRead() shall be enough to determine pin states
• do the math for it: calculate RC circuit for thesis, perhaps (in parallel to math) record it on a oscilloscope [problem is time resolution!!] to see actual results

one good read is https://www.ikalogic.com/de-bouncing-circuits/
another one is http://www.eng.utah.edu/~cs5780/debouncing.pdf

needed are

• autocad drawing with dimensions (inner & outer)
• url of product

draw the battery model so that a holder for them can be 3dprinted and inserted into the enclosure

draw an autocad model of the battery holder, export it into stl

the holder shall be made of plasic, hold two liion batteries securely and attach on the top side to a pcb holding battery connectors, which in turn lead to the battery charger board

draw a OLED display / button holder
draw housing for power connectors

ATM the atmega2560 pins are in some obscure "default" initial state on startup (after setup() is complete).
for clarity's sake implement an initialization code block which shall set all pins and internal devices to known states:

• pins to high impedance
• turn off all needed devices
• turn on only needed devices

the initialization shall be binary values for the appropriate registers; using Arduino libraries for this is not worth the time.
document each setting via references to the datasheet.

the gsm modem shall be implemented in such a way that it can be addressed and configured from within the code and from the user menu.
the code shall initialize it to a proper state, the user shall be able to configure e.g. APN and similar GPRS related items.

the main goal is to be able to upload collected position data and either save it remotely and/or display it on google maps or similar

the SD card (SPI) init seems to interfere with the OLED on I2C.
fix the issue either with utilizing a different OLED (one with hardware SPI) or otherwise.

data in the EEPROM can get corrupted and functionality to detect a corrupt setting and recover from it is needed.

at the moment the menu displays the basic data needed for the tracker to function.
there are a few missing items (battery status, temperature, lineup of menu elements).
most of them are hardware-independent and can be implemented at a later date.

order one set of PCBs via fritzing or similar

implement adjustable GPS logging frequency via the appropriate eeprom field

obtain needed components via rsonline or similar

upload the prototype code, comment it, list open issues and bugs

solder components onto PCBs

bt constant power on/auto /constant off shall be implemented.

atm it is supplied via 100% PWM duty cycle on pin 9

implement a mosfet via which an analog? port shall trigger the gate

the accelerometer shall put the device in a proper sleep state in order to preserve power when no movement is detected.
for this the ADXL345 can trigger interrupt events which the micro-controller has to be able to respond to (go to sleep and wake up after wards).

draw up visio diagrams (or similar) showing a block-diagram like overview of components and features so that sbojanic can understand the apparatus