I have 4 of Mikrotik 'Wap AC's.
3 of them are fine. But the fourth one turned out to be a problem, an enigma.
I have reset it (30-30-30) several times but it just refuses to be visible on LAN --WinBox cannot locate it, doing a full network scan returns nothing.
Also, it has no WiFi presence either since neither of the radios come on line.
My question is this:
Now that I have removed the motherboard from the enclosure, is there any way I can hard reset it? Shorting some contacts or something similar.
You might use the netinstall software and try to upload the correct firmware.
The reset button has three functions:
Hold this button during boot time until LED light starts flashing, release the button to reset RouterOS configuration (total 5 seconds).
Keep holding for 5 more seconds, LED turns solid, release now to turn on CAP mode. The device will now look for a CAPsMAN server (total 10 seconds).
Or Keep holding the button for 5 more seconds until LED turns off, then release it to make the RouterBOARD look for Netinstall servers (total 15 seconds).
Remember boot time is after power is connect that means you must keep hold the reset button.
After that you can follow the steps for netinstall https://wiki.mikrotik.com/wiki/Manual:Netinstall.
Faced with the fact that Netinstall does not see the connected access point, it was decided to disable the firewall. After that, the device appeared and I was able to flash it.
Related
So, I'm trying to connect to a custom board using ST-Link. My board uses STM32 Microcontroller and I use ST link utility software to see if I can connect to it.
Right now, If I press connect on utility software and press reset on my board at the same time, the connection is successful. But as soon as I remove my finger from the reset button the connection to the device is lost. Is this expected? And how can I make it stay connected without me keeping the reset button pressed!
Also, assuming I keep pressing it, the utility software gives me an internal command error when I try to erase chip. this happens when I try to program the chip as well.
Any suggestions are appreciated.
So the way to resolve the issue was to pull-up the NRST pin on the board and st link and disconnect it after pressing the reset button.
I still have not found a solution for erasing the chip but I believe the flash is protected. When I try to change the Option Bytes in st link utility, it disconnects from the board saying:
Could not set Option bytes!
Please reset the target and retry!
And then disconnects from the device.
Any clues how I can change the options bytes? That might actually solve the problem!
Thanks
By my experience all of such this problems come from bad assembling one way that may help you to find out first put a light in the back of your PCB right under your micro-controller and see if any pin is outside of footprint if it is aligned correctly,gently press your micro to the PCB and and test if it is disconnecting if it solves your problem then some of pins are not soldered correctly
I just had an app rejected because I have a user changeable setting which allows the user to disable screen lock via
[UIApplication sharedApplication].idleTimerDisabled = YES;
Apple says I used an undocumented API but it IS indeed documented here: https://developer.apple.com/library/ios/documentation/uikit/reference/UIApplication_Class/index.html#//apple_ref/occ/instp/UIApplication/idleTimerDisabled
My app graphs the barometric pressure and if you want the graph to run longer than a minute or two, it is important to disable screen lock. The default behavior is screen locking as usual, but there's an option in the settings to disable screen lock and this seems to be what Apple took issue with. I've had academic users request this feature, and I have used it in other apps successfully, however this time Apple rejected my app for using it. Is this normal? Is disabling screen lock via UIApplication really now allowed?
I am not sure but I think the issue is that note under the important heading with the documentation you shared;
"You should set this property only if necessary and should be sure to
reset it to NO when the need no longer exists. Most apps should let
the system turn off the screen when the idle timer elapses ..."
You should write into resolution center and confirm this;
We use that capability to prevent idle sleep when we are updating the firmware on a BlueTooth device. Immediately upon completing the update, we restore idle timeout. Apple never said a thing to us about it.
However, in your case, there is no technical reason to disable the idle timer. Your data collection is not going to fail because the system went idle. There is no adverse or unusual customer experience going to be had. That is probably what Apple took exception to.
Three possible paths exist:
1) Gather your data at intervals in the background while the system is idle and update the graph when the app again comes to the front.
2) Add messaging to your app to tell the user that if they want continuous display, they will need to change the idle timeout period in system settings. (With caveats about impact on battery charge duration.)
3) State your case to Apple.
I would go for both 1 & 2
I purchased a RadBeacon USB from Radius Networks and iBeacon Locator on my Nexus 7 says the calibration is: -59.
My iPhone 5s sees it, the measured power is: -64, so I press OK to copy this value to the Measure Power field of the beacon settings. You must apply the settings to update the Measured Power on the beacon device.
So I press Apply and use the PIN 0000.
Apply Settings.
It says "Invalid PIN".
I use my 4 digit PIN that I use for everything and it says "Connection timed out".
Now in the instructions it says "If you are unable to discover you beacon using the RadBeacon Config App, remove the plastic cover and firmly press the configuration button above and to the right of the battery holder. This will restart the 30 minute configuration window and your beacon should show up in subsequent scans.
Define firmly.
I didn't think it had a battery. What is a battery holder?
Does this button give any kind of tactile feedback when pressed so that I can know that I'm pressing it?
There's a square opening on the top-right of both sides after removing the metal cover. Is one of them the button?
Is there a product that doesn't have this 30 minute restriction so that I can get it to work the first time as a proof-of-concept, and not have to worry about it being bricked after 30 minutes?
Sorry you are having trouble, Philip.
You are correct that your RadBeacon USB does not have a battery. We also sell a RadBeacon tag, which does have a battery and it sounds like you are reading the instructions for that model. So please ignore those instructions.
To restart the config time window on your RadBeacon USB, simply unplug it and plug it back in. Then try using the iPhone RadBeacon app to configure it using the default pin of 0000. If it does not accept that pin, and you did not change the pin to something else you remember, contact us at support#radiusnetworks.com and we will arrange a replacement.
Understand that the configuration time window is simply a security feature to keep other folks from trying to reconfigure your beacon. You can always restart the time window by cycling power. So you don't need to worry about bricking your device -- just be careful not to change the pin without writing down the new number.
I've seen claims on the net that the newly released iOS 7.1's iBeacon support.
Specifically:
The system is supposed to still notify your app about
didEnterRegion/didExitRegion events, even if the user explicitly
kills your app.
didEnterRegion/didExitRegion notifications are
supposed to be faster from the background and/or with the device
locked.
I have not been able to confirm either of these claims with my own testing. In fact, I seem to be less likely to get didEnterRegion/didExitRegion notifications from a locked device. (more accurately I seem to get didEnterRegion notices, but not didExitRegion notices). That could be because Apple made me remove my BLE background mode entries in my info.plist - I'm not completely sure. I'm still trying to sort this out.
I had trouble setting up my tests at first, but I have witnessed background region entry callbacks after killing an app in iOS 7.1 on both iPhone 4s and iPhone 5s models. See comments below for testing details and instructions to reproduce.
I have also done tests on background detection times on an iPhone 4S, and I still see delays of 15 minutes on iOS 7.1. My full test results and methodology are described here.
Finally, I have also done some tests on the fluctuations on the "accuracy" (distance in meters) measurement on the same device before and after the upgrade to iOS 7.1. I do not see an obvious difference in the noise on the estimate. The graphs below show results before and after the upgrade, with an iBeacon 0.5 meters away for 60 seconds then moved to 3 meters away for 60 seconds. In both cases, the transmitter was a properly calibrated iPhone 4S w/ iOS 7.1 and the receiver was an iPhone 5S.
iOS 7.0.6 Estimated distance
iOS 7.1 Estimated distance
As has been mentioned in several articles circulating around the internet, beacon sensing is available even when you swipe your app away from the multi-tasking view. However in my experiments, a region enter/exit event doesn't call the didDetermineState: directly (Probably because I hadn't been using the AppDelegate to initiate any beacon sensing but instead triggering monitoring based on UI events). Instead if you have registered for Background Location Updates, your AppDelegate's didFinishLaunchingWithOptions: method would get called with the value for key UIApplicationLaunchOptionsLocationKey in the parameter launchOptions set.
You can do a simple check like this to test if this is indeed a location update that has bought your app into the background to perform some task.
if ([launchOptions objectForKey:UIApplicationLaunchOptionsLocationKey])
You can then either register your monitored regions again or start ranging immediately.
P.S. CLLocationManager retains your previously monitoredRegions on app restore but without starting monitoring again using the same UUID and identity, you would not get the enter/exit region event in CLLocationManagerDelegate (which had brought your back up to life)
David has done some wonderful work on this, so I'm writing this cautiously... but I'm seeing something quite different from him in my tests.
I'm using two phones: an iPhone 4S running iOS 7.1 (11D167) and an iPhone 5S running iOS 7.0.6 (11B651). My iBeacons are manufactured and sold by Bluecats (www.bluecats.com), although I'm not yet using their SDK (ie. I'm just using CoreLocation) and I don't think the manufacturer makes much difference.
I'm getting response times of around 1-2 seconds on both devices when the app is running in the foreground and also when running in the background. The only difference is when I remove the app from the app switcher: iOS 7.0.6 never responds (or perhaps will do in 15 minutes), but iOS 7.1 responds in roughly the same time. When I say "respond", I mean that the CLLocationManager's locationManager:didDetermineState:forRegion: delegate is called by iOS.
I'm testing by actually wandering around my office with phones in hand, so I'm physically moving in and out of range. Strangely (?), in my early testing, where I was sitting at my desk and simulating moving in and out of range by removing and reinserting batteries, I was seeing much slower response times. Perhaps this is part of the difference?
In my testing I have seen the presence of a beacon go un-noticed by an app for up to 15 minutes, but I found something that's interesting. I'm using RedBearLabs mini BTLE sensors as ibeacons and their app to program the beacons, http://redbearlab.com/ibeacon/ (http://redbearlab.com/s/MiniBeacon_v1.zip), seems to have an something in it that immediately starts a scan / update of beacons. If I start a beacon up, and in my app it goes unnoticed, by starting then quitting the MiniBeacon app my app immediately notifies me that there are new beacons. This is the same result when entering or exiting. Their app uses CBCentralManager, which my app doesn't, so maybe a mixture between CBCentralManager and CLBeaconRegion is the way to go? I imagine CLBeaconRegion starts / restarts the bluetooth radio, so maybe that is the reason for this. Just taking a stab at it in hopes that someone with a more complete understanding can help resolve this.
Thanks
My testing also reproduces 15 mins to start scanning when my app is in background mode on iOS7.1.1. Just a bit curious, I have seen quite many youtube videos from different companies showing the app has been waken from background mode as soon as they approach their beacons. Is it sales trick?
I have made an app with live tile for windows phone 8. The tile is programmed to refresh every 30 seconds. When the run the app in the emulator or when I deploy the app in my cell (Lumia 920) the tile works fine. But surprisingly when I downloaded the same app from the market and run it on the same device the tile doesn't update.
I did quite a bit of research on this problem and found that a similar problem is observed by many other people which can be found here.
Kindly tell me what is going wrong.
Extra Info : I have tried resizing the tile, pin and unpin the tile and hard reset. I have also tried changing the refresh period (initially the refresh period was 5 seconds). I have also checked that the background task is allowed for the app.
Thanks,
Apurva Pathak
Background agents have certain limitations, as listed below.
Background tasks can minimally be run every 30 minutes. There is a debug-only API to run them more regularly, but this is not available for released apps.
Some low power devices do not support background agents
Background tasks are limited by number on each device and can be enabled or disabled from application settings.
They do not work when power saver mode is activated.
As Mahantesh correctly pointed out your tiles work when you deploy the application because the ScheduledActionService.LaunchForTest() is allowed to run for a 60 seconds period for debugging and testing purposes ONLY.
Therefore this method cannot be called and it wont work with a time limit less than 30 minutes if the application is published to the market and users download it from there.