sq7bti

Follow-up in https://hackaday.io/project/9268-telescope-controller s.

Hi @@simpleavr, You might try to hand pick values from wider window, but here are Hamming windows size 16 (mind the symmetry): // round(255 * window('kr',16,6)) //const unsigned char hamming[8] = ( 4, 18, 46, 86, 136, 187, 228, 252); //, 252, 228, 187, 136, 86, 46, 18, 4 ); // round(255 * window('kr',16,4)) const unsigned char hamming[8] = ( 23, 51, 88, 130, 172, 210, 238, 253); //, 253, 238, 210, 172, 130, 88, 51, 23 ); // round(255 * window('kr',16,2)) //const unsigned char hamming[8] = ( 112, 141, 170, 196, 218, 236, 248, 254); //, 254, 248, 236, 218, 196, 170, 141, 112 ); More inf

Hi, Having a nice matrix led display laying around with no use of I assembled a test circuit with launchpad and modified the code of @simpleavr to run on it. The display is driven by four MAX7219 chips chained on SPI bus. I noticed that the only floating point operation that your code was using is a square root operation in line 257. Once I added a fixed-point square root routine, linking with math lib is not necessary anymore - spared a lot of flash space. The fixed-point routine is also 3 times faster than mathlib floating point one: 50us vs 150us #ifdef FLOATING_POINT // sqrt: 150u

Gratis verzending: http://tweakers.net/pricewatch/473997/raspberry-pi-zero.html s.

Formulas for US and EU beginnings and endings of DST: For the United States: Begin DST: Sunday April (2+6*y-y/4) mod 7+1 End DST: Sunday October (31-(y*5/4+1) mod 7) Valid for years 1900 to 2006, though DST wasn't adopted until the 1950s-1960s. 2007 and after: Begin DST: Sunday March 14 - (1 + y*5/4) mod 7 End DST: Sunday November 7 - (1 + y*5/4) mod 7; European Economic Community: Begin DST: Sunday March (31 - (5*y/4 + 4) mod 7) at 1h U.T. End DST: Sunday October (31 - (5*y/4 + 1) mod 7) at 1h U.T. Since 1996, valid through 2099 (Equations by Wei-Hwa Huang (US), and Robert H. van Gent (

Thanks for your input. BTW, Regarding the timer used by other libraries I also discovered why I had problems with Timer1: there was a conflict because in my project I am using pin PF_3 for PWM generation with analogWrite(). Perhaps it would be even more flexible yet safe to allow selecting (with begin() method) a specific timer instead of choosing timers one by one from the list of hard-coded list of available ones.

Hi again, I improved the code further: the driverlib calls were replaced with direct HWREG() writes and reads. I found the timer1 unreliable - as far as I can see it is not used for anything else, and when used for triggering steps it is "stuck" after a while. So far I was not able to find the root-cause of this problem - it is only apparent with timer1 - not with the two remaining timers 2 and 3. https://github.com/sq7bti/iAccelStepper iAccelStepper.h #ifndef iAccelStepper_h #define iAccelStepper_h #include <Energia.h> #include "AccelStepper.h" #include "driverlib/sysctl

Progress: A summary of changes: instead of unipolar motor drivers, now I used a bipolar drivers very popular in RepRap projects, here A4988 (or DRV8825) 28byj-48 modified for bipolar cheap HC-05 for bluetooth SPP GPS module U-blox NEO-6m added RTC DS1307 to provide date/time reference even in the first seconds after power-on and 56 of NVRAM bytes added (optional) humidity and temperature sensor DSTH01 added a I2C socket to connect external temperature sensors to provide information about motors temperatures added PCF8574 for microstepping configuration of A4988 drivers added buzzer for au

Check with a digital probe an order of sequence the motor is excited. If improper, the rotor would shake instead of turning. The same would happen if the wiring is incorrect. You might also try swapping motor wires, if you are not sure what order they should be. What motor are you using, by the way? Yet another option is that the timing is incorrect: try lowering the motor speed and acceleration. s.

What motor driver chip are you using? What AccelStepper::MotorInterfaceType did you specify? s.

What specifically didn't work? Compilation error? Unexpected behaviour? S.

I got it all up and running with 1307, just as I wrote: Vbus as supply (5V) and with 3.3V on pullup i2c resistors. PCF is not available in DIP, while DS1307 is. Thanks for the hint anyway. Addendum: Besides, the DS1307 features an NVRAM. Comes handy for the project I am working on right now: newtonian telescope controller: store mount specific configuration instead of compile-in.

The first four looks like some web-mail referenced links. Just take a look at the beginning: https://mail.jbu.edu/owa/redir.aspx?C=f89ce17e5c8847cea19d0f2fb00cbfae&URL=http%3A%2F%2Fwww.ebay.com%2Fitm%2F10DOF-IMU-HMC5883L-ITG3205-BMA180-BMP085-Sensor-Module-For-MWC-Arduino-%2F321180164174%3Fpt%3DLH_DefaultDomain_0%26hash%3Ditem4ac7d4604e Great project by the way. s.

Please correct links. s.

Thank you Stendall. It helped a lot. In my case there was another issue caused by the following feature i overlooked: (page 6 of DS1307): Upon power-up, the device switches from battery to VCC when VCC is greater than VBAT +0.2V and recognizes inputs when VCC is greater than 1.25 x VBAT. The chip was responding correctly when powered from launchpad 3.3V bus, even though nominally it is 5V device, but played dead when 3V battery was connected to it at the same time. DS1307 is fine when powered from 5V, with SDA and SCL pulled up from 3.3V. s.

It is indeed true for i2c-scanners as far as I can see in the code: uint8_t TwoWire::endTransmission(uint8_t sendStop) { uint8_t error = I2C_MASTER_ERR_NONE; if(TX_BUFFER_EMPTY) return 0; //Wait for any previous transaction to complete while(ROM_I2CMasterBusBusy(MASTER_BASE)); while(ROM_I2CMasterBusy(MASTER_BASE)); //Select which slave we are requesting data from //false indicates we are writing to the slave ROM_I2CMasterSlaveAddrSet(MASTER_BASE, txAddress, false); while(ROM_I2CMasterBusy(MASTER_BASE)); unsigned long cmd = RUN_BIT | START_BIT; error = sendTxData(cmd

Hi Stendall, Would you please explain how did you solve your problem with I2C? I guess I tried all suggested solutions in this (and other) threads, including: - checking with other modules - different combinations of initializations, setModule statements, and begin() - checking with lower Rpu (according to the philips document it should be approx 1kΩ My conclusion is that no matter which module I use I get always get 0 (null) back from endTransmission(), no matter if there is ACK or not. That makes the detection of I2C failed transaction wrong: i2csdetect erroneously detect a device

I decided not to start another thread, because what I am about to present here is actually my attempt to port AccelStepper library to LM4F. Specifically my port makes use of the timer interrupts to schedule stepping, instead of using polled fashion execution of run() method. I used the AccelStepper source code revision 1.39 and I had to move around number of members from private to public: _stepInterval _direction _currentPos _targetPos _speed _pin[4] Modified AccelStepper can be used for inheritance. It is limited to the DRIVER variant, but can be easily extended with FULL4WIRE, HALF4WIRE an

Hello again, The hardware can be easily described with pin assignment, as most of the connections are straight forward: Software on the other hand comprises of the following modules: GPS - NMEA stream is parsed by TinyGPS++ LCD facilitated by SPI Sidereal time calculation - header file holds the Sidereal time for midnight each day precalculated to optimize execution AxesLib with help of AccelStepper provides interface to drive the mount around in azimuth and altitude coordinates, but also during start-up performs homing and calibration of mount (play estimation), CoordsLib performs tra

When powered on, the mount moves to the first alignment star. Then, a user provides the correction vector: star just needs to be positioned in the middle of view in eyepiece. First star roughly corrects the misalignment in telescope orientation w.r.t. the north. Second star helps to correct also the leveling error. Third star would improve alignment even further. I did not (yet) implement any periodic error correction. The whole alignment procedure takes couple of minutes, and requires a user to center stars in an eyepiece with an attached joystick, and confirm with fire button. GPS resolves t

Hello everyone, There is a couple of similar projects available on the internet. Some of them base on Arduino and PIC performs very basic mount control without math intensive computation implemented in embedded controller. I decided to build my own with the following goals: ease of use by an inexperienced amateur astronomer (full automatic operation) precision and resolution of position last but not least: the price Final, or better say at the moment, design comprises of the following components: Stellaris LM4F launchpad central control unit, two ULN2003 unipolar stepper motor driver ch

I had similar problem. Perhaps it only worked for me, but you might try the same, so we could verify and that would give some hints to the developers: Rename constructor to a method in AccelStepper.h and AccelStepper.cpp, for example: void AccelStepper::begin(uint8_t interface=AccelStepper::FULL4WIRE, uint8_t pin1=2, uint8_t pin2=3, uint8_t pin3=4, uint8_t pin4=5, bool enable=true) { // paste the original constructor method here } Make an empty default constructor for AccelStepper in AccelStepper.h: AccelStepper::AccelStapper() {} Use it in your code: AccelStepper mystepper; void

Hi worstell, Thank you very much. I have taken the liberty of implementing that idea into my code. What came out is an 8 digit display driver using the very same number of pins as the 4 digit version I had started with. It looks OK, if you don't care about the flickering of some segments that supposed to be off. It is apparent that making the nodes floating still results in residual currents floating in unwanted branches. This is justified by REALLY simplistic and minimalistic hardware. My code allows to manipulate duty cycle for both displays separately - as you suggest it is possible to

Hello fellow 43oh'ers ! I have coded a similar thing myself just recently to replace a hard-to-get saa1064 I2C display driver chip. My objectives were therefore a bit different, namely I wanted a full functional replacement. Circuit simplicity is a pro, as it requires barely a handful of current limiting resistors, display and an USI capable MSP with at least 12 gpios available. The code can be found in google code repository (url will follow). Feedback is more than welcome, as I am new into micro-controller programming. http://code.google.com/p/msp430-saa1064/ s.